Code doesn’t care whether you are new to programming or an old pro, a citizen developer or the head of engineering, some missteps can catch any of us. Read on to learn some of the most common programming pitfalls and how to avoid them.
To help developers check if their software is ready for 64-bit, Apple added a new tool for developers in Xcode 9. With this tool, you can force macOS to run as “64-bit only” to see if your software is ready for a 64-bit only environment.
In the Mac world, 32-bit apps have been disappearing more and more as time goes on. This year already we’ve seen significant steps toward 64-bit.
In January 2018 Apple stopped accepting 32-bit app submissions to the Mac App Store.
In February 2018, starting with macOS 10.13.4, Apple added a warning that displays the first time you launch a 32-bit app.
In June 2018 Apple stopped accepting updates to 32-bit apps in the Mac App Store. All new apps and app updates must now be 64-bit.
At WWDC 2018 Apple announced that macOS 10.14 will be the final version that support 32-bit apps. Although they did not announce a release date, based on the timing from the past few years macOS 10.14 will probably be released around the end of September 2018.
Viruses continue to be a big problem on Windows. As a result, anti-virus software can be a bit over-zealous about detecting what it believes to be apps that have viruses embedded within them. We have had reports over the years that apps made with Xojo are sometimes falsely identified as being infected with a virus. This sometimes occurs because the 32-bit Xojo compiler puts executable code in a location where the anti-virus software doesn’t expect to find it. We’ve seen this occur even when users are debugging apps from the IDE. Fortunately in that case, there’s a fairly easy solution.
Once the front end has done its work its time for the back end components to take over.
This is the fifth in our compiler series and the first on the back end. We covered the parts of the compiler that are called the front end in these posts:
Back in 1998 when we shipped version 1 of what is now Xojo, it was a 32-bit application and has been ever since. Depending on the operating system, that meant the Xojo IDE itself had at most 4GB of RAM available to it. That would seem like more than enough for any project. However, we have some users that have really big projects. One project I know of has over 1500 project items!
In his poem, “The Mouse”, Robert Burns wrote:
The best-laid plans of mice and men oft go astray…
As Burns so eloquently stated, no matter how carefully you plan sometimes things just don’t work out. Anyone who has done software development for long knows this all too well.
Our goal has always been to let you focus your energy on what makes your app unique. One of the ways we do that is by handling the nitty-gritty details of the various platforms Xojo supports. For example, you don’t have to worry about the differences in how files are accessed on Windows, Linux, macOS or iOS. We take care of that for you.
Saying all this is one thing, however, and delivering it is quite another. We’ve been through some significant technological hurdles over the years. Over the past 12 months we’ve had two big transitions. The first was support for HiDPI (called Retina on macOS and iOS) which made it possible for apps created with Xojo to support high definition screens. For Xojo users, adding HiDPI support was mostly a matter of recompiling their app. If they had pictures or icons, higher resolution versions needed to be supplied but aside from that, it was effortless.
The second big feature we’ve been working on is support for 64-bit. Integers are the issue here and are almost certainly the most common data type used in apps built with Xojo. If you have used the generic Integer type, in theory, building a 64-bit version of your app should be a simple matter of recompiling. That’s the theory. What’s the reality?