Photo by Daniel Eliashevskyi on Unsplash While the Mac may have lost its original performance advantage over Windows, it retains a committed body of users, especially in the media area, and hardware holds its value far better. An 8-year old MacBook Pro laptop sells for more than a new Windows laptop of the same screen size with superior performance. Developer of desktop applications rarely have to choose between Mac and Windows platforms but may have to become proficient in one platform after many years of working on the other. Any desktop operating system has to support a means of developing software for its platform. The native Integrated Development Environment (IDE) products for this purpose for Mac and Windows are Xcode (VC) and Visual Studio (VS), respectively. Visual Studio is also available for recent operating system versions on Macs, but it relies on the Xcode Interface Builder. Both products have free or ‘community’ versions. The paid version of Visual Studio has features useful for a large development team, such as access to a version-controlled repository. Both Visual Studio and Xcode are large, highly complex products, both supporting many types of applications and components in multiple languages. Visual Studio offers some multi-platform options, but only for applications without a graphical interface. Visual Studio add-ons such as ETO are available which provide some multi-platform interface facilities, but these are much less comprehensive than those available for Windows. Xcode only creates applications for Apple hardware, which use a range of operating systems, all Unix-based. Applications written in Java can be run on any platform with a Java Virtual Machine, such as macOS, Windows or Linux. A review of cross-platform application tools is available for further reading. In pursuit of improved performance, Apple is currently changing the Mac platform from using Intel x86 chips (as used in PCs) to using custom-designed ARM (Advanced RISC Machines) ones under the banner name of Apple Silicon. Although Macs do not have a great history of backwards compatibility, one report states that most applications built on Intel Macs should run on machines using Apple Silicon. The lack of backwards compatibility means that many media professionals run old versions of macOS as their software requires an expensive upgrade to run on later versions of macOS. Analysis of 2100 visits to a commercial website for 5 months prior to May 2021 indicates that macOS users only account for 7.5% of visits. Of these 7.5%, 65% used macOS 10.15 or earlier rather than the latest version (11.x), which was used by only 15% of Mac users. By contrast, 93% of Windows users used the latest Windows 10 release. Some of the differences in use of the latest OS between Mac and Windows may be because MacOS 11.0 was only released in November 2020, whereas Windows 10 has been available since 2015. 40% of Mac users used Google Chrome rather than the native Safari browser. 70% of Windows users preferred Google Chrome, with only 11% opting for the native Edge browser.
Mac Development
In the broadest of terms, the Mac development environment can generate sophisticated apps and requires little or no coding to deal with mundane but important attributes such as handling form resizing. However, it has a daunting learning curve and minimal documentation. The single-screen design requires constant juggling unless large or multiple screens are available. Developers are steered toward App Store deployment. This has the advantage of easily reaching only Mac users, but the developer registration fee and the loss of up to 30% of license fee income may be offputting. There are also considerable restrictions on the app itself, which is subjected to a checking process involving automated and human review. There are also restrictions on the use of encryption, and the use of https links requires completion of US Government form. Dealing with the problems detected requires Googling the received message and seeing how other users have dealt with the problem, as the messages themselves are terse. Independent deployment via .dmg files is possible but requires developer registration to avoid installation obstruction. The development process is made more difficult by limited text search and editing facilities and the lack of utility of call stacks, which frequently do not indicate how to trap user interactions, as they do in Visual Studio. Extensive use is made of binding interface components, but the means of achieving this are not clear. Failures in binding operations can be very difficult to diagnose. The composite nature of interface components such as buttons and combo boxes may be confusing. The Model-View-Controller design pattern underlying Xcode is elegant and theoretically attractive but can result in severe confusion after an interface is designed and the time comes to programmatically access controls or events. Outlets and/or actions have to be defined for each control and the means of doing this (ctrl-dragging onto an ‘Assistant Editor’) is anything but obvious. Like many things about the Mac, it’s easy – when you know how. By contrast, accessing Visual Studio interface controls and events is amenable to discovery by experiment. If you ask for online help in forums such as Stack Overflow with any aspect of Mac development, be prepared for some irate responses. Mac gurus have little tolerance for questions whose answers they deem to be obvious, even if they are not so to a novice user. Visual Studio labours under the requirement of maintaining 32-bit compatibility and occasionally refuses to display the design view of forms (in a WinForms app) unless a particular platform is chosen. For large, complex code assemblies, compile error detection may fail by indicating non-existent compile errors. Restarting Visual Studio usually fixes this. Xcode’s most irritating bug is failure to display code in the Assistant Editor window. Display of this code and the facility to drag and drop onto it from the graphical interface is core to developing Xcode applications. Numerous workarounds are described on Stack Overflow to fix this problem but finding the one which works can be very time-consuming. The most catastrophic Xcode problem is its occasional failure to read internal xml files. This results in an inability to edit the interface via storyboard files, or to view or edit Project or Target properties, or project .plist data. There is no workaround other than using an earlier project version where xml files are read successfully, and merging in later changes in .swift files. Other Xcode problems include failure of Swift debugging and for Mac apps, failure of menu operation. Apps developed in earlier versions of MacOS may present a different (and sometimes non-functional) interface on newer versions. Apple have attempted to deal with this problem by only accepting App Store submissions from Xcode 13 or newer, which requires a more recent MacOS version than Catalina (10.15). Analysis of crash data from MacOS apps is difficult - the raw crash logs only show binary addresses, not the line number of the routine where the crash occurred, as Windows does. Xcode attempts to process these logs to show the location of offending statement but this process does not always work.
Interface
Both Visual Studio and Xcode offer a large number of options for coding different types of objects for different platforms with different languages. Differences between the two are immediately apparent: cross-platform for Visual Studio includes Windows, all Apple operating systems, Linux, Android and Xbox, whereas multi-platform for Xcode means macOS and iOS (used for Mac and iPhones & iPad, respectively). There is no support for non-Apple operating systems. However, Visual Studio’s capabilities for non-Windows platforms are limited to applications without a graphical interface. Various third-party add-ons are available to provide cross-platform graphical interfaces but facilities are generally limited. Visual Studio for Mac allows development in C# on a Mac, but interface design uses the Xcode Interface Builder. Within Visual Studio developers for Windows have the choice of Windows Forms Applications (WinForms) or Windows Presentation Foundation interfaces. WinForms applications are simply a layer over standard Windows controls and have the distinctive Windows ‘grey box’ appearance. WPF applications are much more flexible in appearance. You can read a more detailed breakdown of the differences between the two. There is also a choice to be made about whether to use .Net Framework or .Net Core (Core is often omitted, as this is the new Microsoft standard). .Net Framework has been in use for many years, and a large number of components are available which make use of it. .Net Core is relatively new.
Text Editing
Software development involves a great deal of editing of text files containing source code. Both Visual Studio and Xcode store source code in a single text file for each higher level object (forms or modules in Visual Studio, classes in Xcode) with individual routines defined by a particular syntax within source code files. Visual Studio allows selection of routines via a dropdown of alphabetically sorted routines and vertical scrolling of the display via a scrollbar. Xcode code display can only be scrolled using the up and down arrow keys—there is no up and down arrow for scrollbars. Xcode does support stepping up or down by a screen height (by holding the function key while clicking up or down arrow) The default ordering of routines in Xcode within classes reflects their ordering in the source code file, but markers can be placed which assist in grouping routines. Alphabetic ordering is possible (using command-click on the dropdown) but is not the default. Xcode search presents its results in a separate pane to the source code as shown below, which is useful but does not offer the range of search scopes of Visual Studio (current block, current document, open documents, project and solution). Although the differences between Xcode and Visual Studio text editing capabilities may appear minor, the intensity with which they are used makes the superior capabilities of Visual Studio attractive.
Coding
Xcode supports Objective C (the original Mac language) and Swift (a more modern replacement). The languages have the fundamental difference that the default for Objective C is to pass parameters to methods and functions by reference, whereas the Swift default is to pass them by value. The two languages are not interchangeable, as Swift contains features not found in Objective-C, whereas the two main languages supported by Visual Studio (C# and Visual Basic) are largely interchangeable, and online converters between them can be found. A major deficit of the Apple development environment is the poor quality of help. The macOS and iOS operating systems contain some extremely powerful components, particularly for graphics operations, but implementing them is often a matter of trial and error and adaption from existing open-source code. Relevant open-source projects may be written in either Swift or Objective C and may need conversion before they can be utilised. Example projects may also be very old and contain obsolete features which may need replacing.
Debugging
The software development process may include large amounts of time stepping through code one instruction at a time and examining the values of variables. Both Xcode and Visual Studio support this, but the panel displaying the values of current variables in Xcode only displays variable values within the routine as shown below. Decoding may not be correct for complex objects or when using po (Print Out) in the debug window to view objects, (Boolean values appear as dates). The variables window does not always show attributes visible to the user, such as text values in NSTextFields. These must be shown by po commands in the debug window at the lldb prompt as shown below: Both Xcode and Visual Studio support a try-catch-finally structure for run-time error handling but the Xcode exception object does not give the source code line being executed when the error occurred. Exception data tends to be cryptic on both platforms and is sometimes absent in Xcode.
Persistence
Windows provides persistence of values between runs using the Windows Registry, with separate tables for global and user-specific values. This is a database, which can grow very large. Only a small number of data types are supported. macOS uses a per-user file structure, called a property list (or plist) which can support many different data types, but caches the stored values in memory, so parameters cannot be changed by editing plist values unless the cache is cleared with the command defaults delete
Installation, Upgrades and Uninstallation
Visual Studio installer creation was originally a native capability but was later replaced by a cut-down commercial package (InstallAware LE), but the 2019 version returned to a native capability. However, it is complex to configure. A Visual Studio install project creates an msi (Microsoft Silent Installer) package, which is a database containing all the required components. These can be deployed, but self-extracting executables have a number of advantages. Preparing these requires the use of 3rd-party components. Download of both .exe and .msi file types may be blocked by some browsers, as they may both contain malicious code. Installation is straightforward in Windows if there has been no previous installation, but upgrading is more complex—objects required by the application are only replaced if their version number has changed, and this does not happen automatically. Failure to do this results in run-time errors. Uninstallation is complex—executable objects, library files and registry entries have to be removed, and if the original installer is not available the uninstallation cannot proceed from a script and has to be performed manually. Universal Windows Programs (running only on Windows 10) have greatly simplified application management but at the cost of presenting applications in two different locations, so finding an application may not be straightforward. Creating an installer for a macOS application is fairly simple, although non-intuitive in that it is performed using the Product→Archive menu options. The resulting files can then be processed with Disk Utility to create a dmg file, which can then be deployed. Notarisation is required to avoid obstruction during installation. A search to find instructions for this process is recommended as it is not intuitive. macOS treats applications in the same way as files but what appears as an application icon is actually a disk image (with extension .dmg) containing all files required by the application, but not the persisted values. macOS displays these disk images in the same way as files. Double-clicking on a dmg runs the application, and dragging it to Applications folder makes it available in the same way as any application. Dragging the application to Trash uninstalls it. When applications are downloaded from places other than the App Store, a dmg file is created in the Downloads folder. While the application can be run by double-clicking on the dmg file in situ, it will not appear in the Applications list unless the icon shown after double-clicking the dmg file is moved into the Applications folder. This can be done automatically using LetsMove CocoaPod. If macOS applications are to be hosted on an independent website, a MIME type may need to be defined for .dmg files in the Web server software. Failure to do this may result in the file being inaccessible for download. Upgrading is simply a matter of dragging the application icon into the Applications folder and replacing existing items. However, persisted values are not stored in the disk image and these remain on disc and in memory after uninstallation, so re-installation does not provide a complete refresh unless the disc file is removed and the cache cleared.
Mobile Devices
Microsoft moved out of the phone market some years ago, probably in response to the success of Android devices in this area. Apple retains about a 50% market share of the phone market with the iPhone, and a somewhat smaller share of the tablet market with the iPad. Development of software for Apple mobile devices is done using Xcode on Macs, which have simulators available for the large range of iPhone and iPad models. Software (or apps) for Apple mobile devices can only be made available natively via the Apple App Store, and need to pass a review process before being made available. The time taken for reviewing can vary between hours and months. Some aspects of app operation (especially those involving e-commerce) cannot be implemented in simulators and attaching an Apple mobile device to the Mac may be required in this case. Developers also need to register as Apple Developers (at a cost of US$100 per year). A further restriction is that only apps developed using Xcode 13 or newer can be placed in the App Store. This requires the MacOS version to be Big Sur or newer. Apple take a commission of 30% on sales through the App Store (15% for small companies). This commission rate is higher than that charged by PayPal, but no additional e-commerce component is required. Payment is on a monthly basis, rather than being immediate as is the case for PayPal. Apple encourage developers to price apps with a subscription rather than a one-time payment, and there are a number of products (such as Glassfy and RevenueCat) which attempt to simplify this process. Developing a free app is much easier! iPhone/iPad apps may suffer from lack of visibility in the App Store, especially if they have keywords used by other apps, due to the massive number of applications available (about 5 million in 2022). Search result ranking is based on the number of 1st time downloads over a period of time, which is obviously zero for a new app. Some form of external advertising will usually be required, based on a unique app name, which should be carefully chosen. Android apps for mobile devices can be developed in Visual Studio and made available via the Google Play Store. A similar registration and review process, and commission structure on sales applies. The one-time developer registration fee is US$25, making it considerably cheaper than Apple’s. The reviewing process appears to be less rigorous than Apple’s, judging by the number of Android apps which do not perform according to their descriptions. Play Store does not show apps which will not run on the version of the devices version of Android, whereas the App Store shows them, but indicates that they require a higher version and blocks downloads. Visual Studio allows creation of multi-platform apps, but the scope of a multi-platform app is generally limited and successful apps available on multiple platforms usually have separate code bases.
Security
For many years, Macs achieved ‘security through obscurity’, relying on the folklore “Macs don’t get malware’. However, this reputation arose largely from Mac’s small market share in recent years. As a result, Macs were not an attractive target for malware developers and they offered no screening for applications not installed from the App Store, such as is provided by Windows Defender. However, since the release of macOS 10.15 (Catalina) in 2019, macOS included a GateKeeper component, which obstructs the installation of applications that have not been “notarised” in the same way that Windows 10 warns about installing unsigned applications. The notarising process uploads the application and checks that it does not contain malware. If this is the case, the application can be downloaded and installed without triggering GateKeeper. Whether Apple notarisation is any more thorough and up to date at malware screening than other anti-malware products is not clear, as the majority of malware for desktops and laptops will target Windows. GateKeeper obstruction is much more substantial than that raised by Windows, which only requires clicking a button to install an unsigned application. Un-notarised applications can only be installed by accessing the macOS System Preferences. This feature is consistent with Apple’s approach of making developers prefer to provide Mac software via the App Store rather than from other sources. (For iPhones and iPads the App Store is the only option.) The pros and cons of using the App Store have extensively discussed—search for “App Store Review” on your browser for latest article. Notarising requires an Apple Developer account which costs about US$100 per year. Windows code-signing certificates are available from a number of cyber-security providers (such as Comodo) at varying prices, which are generally less than the cost of an Apple Developer subscription. However, the process of obtaining a certificate may be very slow and involve substantial enquiry to ascertain the bona-fides of the applicant, which are particularly onerous outside the United States.
Conclusion
External factors usually dominate the choice between Macs and PCs for development, rather than the merits of the development environment. For audio, photo or video editing, Macs are still commonly used—their generally superior performance compensates for the higher price tag. To tap the massive iPhone/iPad and the smaller MacOS markets, development on a Mac is required. Microsoft is making strenuous attempts to move into mobile development as Android devices have become more popular, and attractive features of the Mac often find their way into Windows. Mac developers are often extremely knowledgeable (at least the ones posting answers on Stack Overflow) but may have little patience for novices asking questions they deem to be obvious or inadequately described. The absence of any useful help from Apple makes use of forums essential for dealing with development problems. This content is accurate and true to the best of the author’s knowledge and is not meant to substitute for formal and individualized advice from a qualified professional.
