iOS App Development

The iOS platform is much less fragmented than Android and devices running older ver- sions tend to be discontinued fairly quickly making support and testing easier as there are fewer devices and versions to worry about. However, the requirements are a lot stricter for releasing apps on the Apple store. Unlike for the Android platform there is a strict review process which an app must pass before it can go into a beta-test available to anyone not registered as part of the development team. The terms and conditions to which an app must conform to pass the review process consist of close to two-hundred points spread across twenty-nine categories30_{. The Galaxy Portal app was submitted and}

approved by Apple, but the process took eight days in contrast to on the Android plat- form where it was not reviewed and available a few hours after being submitted.

According to the conditions an app must do something useful, unique or provide last- ing entertainment and must be well designed according to their guidelines. There are also many restrictions on the content an app may contain on matters such as religion and vi- olence, and less obvious restrictions such as not mentioning competing mobile platforms. While these conditions certainly made it harder to get the app into early testing on the iOS platform the real problem turned out to be that some of the terms block the use of such open-source licenses as the GPL and LGPL. This legal hurdle turned out to be a big- ger problem than the technical challenges and we shall elaborate on this in later chapters.

Unlike for Android, a Mac computer with a recent operating system and the latest ver- sion of Xcode installed is required to deploy an iOS app. The iOS SDK is also required and contains the necessary tools and framework for building an iOS app. A device must be connected to actually build a release version of the iOS app and for Xcode to accept this device as a target it must first be registered in the online Apple Developer member centre.

With the iOS SDK installed an iOS simulator also becomes available from Xcode which can be used to run different versions of iPad and iPhone devices to see how the app will

30 See the App Store Review Guidelines: https://developer.apple.com/app-store/review/guidelines; accessed January 25 2015

4. MOBILE DEVELOPMENT

behave with different versions of the iOS and on different screen sizes.

Similar to the Android manifest, an XML Info.plist configuration file is used by iOS. It is used to set product names, versions, icons and other information relevant to the app such as running in background mode as we shall look at in chapter six. The XML is for the most part a simple series of key-string pairs that set various values for the named keys.

To deploy an iOS app from Xcode it must be assigned a unique bundle identifier (typic- ally based on a URI connected with the project together with the app name) and have a version and build set. It must also be signed with a developer ID certificate and assigned to a team which downloads and embeds the required “provisioning profile” from the member centre after logging in. In this case “the team” was just a single developer en- rolled in the iOS developer program which costs $99 per year. We shall not go through all the settings here, but note that the deployment target was set to version 5.1 which was released in 2012 and so supports pretty much all iOS devices except the first iPhone and its successor the iPhone 3G.

The web-based iTunes Connect tools are used to manage the app for testing and dis- tribution. Once the app is compiled, Xcode is used to validate the app and then create an IPA archive file (this is jut a regular ZIP file with a specific file and folder structure). This process will abort and report errors if there are missing icon formats for any supported devices or the Info.plist configuration is incorrect – such as failing to set the “LSRequire- sIPhoneOS” key to “YES” to indicate that it is an iOS only app (deploying to Mac OS X re- quires a separate developer membership). Once all errors are resolved it becomes pos- sible to submit the archived app to iTunes Connect.

In iTunes Connect the app can be made available for up to 25 internal testers re- gistered as part of the team developing the app - for up to thirty days. To progress to ex- ternal testing, with a limit of 1000 testers, it must first pass the App Store review guidelines. As we shall see in chapter seven, the GPL open source license is not compat- ible with the terms and conditions, so a commercial license had to be purchased and a new version created specifically for the iOS platform.

4.1.3 Windows Phone

Windows Phone was only fully supported in the very latest 5.4 version of Qt that was released in December 2014 and as we have seen is much less popular than either Android or iOS. For these reasons, and due to the lack of an actual Windows Phone to work with, a Windows Phone app was never released. However, once it became suppor- ted in Qt the process was explored as briefly outlined here.

4. MOBILE DEVELOPMENT

The Windows Phone app must be built on a Windows system with Microsoft's Visual Studio developer tools installed together with the Windows Phone SDK. The developer tools include a Windows Phone emulator for testing. Windows Phone apps were distrib- uted using the XAP archive file format which contained a manifest file and the binary dy- namic link libraries (DLLs) that make up the app. However, this is replaced with the re- lease of Windows Phone 8.1 by the APPX file format used for Windows 8 Metro applica- tions.

To distribute the app on the Windows Phone Store a developer account is required. An account for individuals and students can be obtained with a Microsoft account and 113 NOK fee.