API Development

Common Support Questions: iOS

With the recent addition of our free Indie Plans for both Titanium and Hyperloop, we’ve seen an influx of new developers join the Axway Appcelerator community. So, we wanted to create a resource for users to troubleshoot their most common development issues and questions for each platform. For the second installment of our series (see the first on Android development here), we take a look at some of the most common support questions for iOS development.

(In this document we’ll be linking off to existing posts, articles, and guides and updating it based on comments and suggestions from you, so please leave a comment below.)

Q: How can I enable Push Notification implementation for iOS users?

A: Typically, and when using the standard iOS process of registering for a push notification, you need to ensure your backend service has the relevant certificates required to enable push in your application.

Firstly, you need to ensure your app has a valid app ID and provisioning profile created with the Apple Developer portal. You need to ensure you have created a provisioning profile to support push notifications OR edited the profile to enable Push as a service. Next, you need to create a push certificate for your application. Typically, the push certificate is uploaded to your backend provider, and associated with the development or production mode of your app.

At this point, your backend provider should be linked with the Apple Push notification system. This is typically where things can go wrong – so if you have any issues it’s worth checking that push is enabled in the profile, that you’ve created the correct certificate, and that you’ve uploaded this to the right place in the backend.

Next and in your application code, you’ll need to register for push notifications – this will create a device token that will be stored with your backend provider and associates the device, so that it can receive push notifications.

Many providers allow for you to add channels and other information to device registrations, allowing you to associate user accounts with devices, or group devices and users so that you can send pushes out to them more easily.

Find out more about iOS push notifications with the Axway Appcelerator Platform.

Q: How do I certify/register my iOS app with Apple, and install it on a device for testing?

A: There are quite a few hoops to jump through before you can deploy an app to an iOS device for testing. Here’s what you do need to do:

  1. Register with Apple’s Developer program: Anyone can download the iOS SDK and development tools from Apple free of charge. Simply visit their website and register for the developer program.
  2. Obtain a developer’s certificate: Once you’ve been approved by Apple, you can then login to the Apple Dev Member Center, and begin the deployment process. Depending on how you’ve set up your account (as a personal or company account), you’ll have a slightly different experience, but essentially you need permission to create certificates. For a personal account, this would be you, but for a company account you will have a Team Agent who is the person who oversees development and final distribution of your app. They have the power to approve or reject developer certifications for your organization. Normally, this would be you, but if you’ve been added to another Apple Developer account, you may not have these permissions, so worth checking with the account owner.
  3. Register your test devices: Apple limits you to testing your app on up to 100 devices per year, each of which must be registered using the iOS Certificates, Identifiers & Profiles page (you’ll become very familiar with this page). You can’t remove or switch out a device once it’s been assigned, so be thoughtful about the devices you register to make sure you don’t run out of spots! You can find out your device ID by looking in the Settings app, or connecting to iTunes or using the Devices and Simulators tool in Xcode (Menu > Window > Devices and Simulators).
  4. Create an App ID: This is simply a unique identifier for your app. Typically it’s a reverse domain name notation. For example, com.mycompany.myapp
  5. Create and install a development provisioning profile: Once you complete the previous steps, you can create and install the development provisioning profile. This creates a provisioning profile with the certificate, adds in the initial devices and allows you to install to the device.(NOTE: There is an ad-hoc provisioning profile that’s also created for each developer account and allows you to quickly deploy to a device for testing, but you can’t send these builds to anyone else.)
  6. Build your app, embedding the profile within the app’s bundle: Using Studio or the CLI, you can now install your app, associating it with the relevant provisioning profile and with your device plugged in and unlocked. When you first connect your iOS device, you might have to have it configure the device for development.

For more detailed instructions each of the steps listed above, please read more here. There are also instructions for distributing your app to remote testers.

Q: How do I distribute my iOS application, and what are the differences in distribution builds?

A: Publishing your iOS application involves a few more steps. Fortunately, if you deployed your app to a device for testing (detailed above), then you are already halfway there. Some of the remaining steps will also look somewhat familiar, and those are:

  • Create and install the distribution certificate
  • Create and install a distribution provisioning profile
  • Build your app and embed the distribution provisioning profile
  • Upload the app to iTunes Connect and kick-off the Apple review process or distribute your application package

For step-by-step instructions on each of these, please click here.

Depending on which developer program you belong to, Apple provides three ways to distribute your app: App Store or iTunes Store, In House and Ad Hoc.

  • App Store is the build that you are probably most used to seeing, with apps appearing within the App Store or iTunes. Apple has published guidelines describing what they look for when deciding to approve an app for these stores. We encourage you to read them carefully, as well as check out our guide on common mishaps when submitting apps for approval.
  • In House is designed for deploying an app for use by employees only. Members of Apple Developer Enterprise program will use this option.
  • Ad Hoc is the build type for those who want to publish an app as a package that can be distributed on a limited number of devices for testing. For this type of build, you need to give the provisioning profile and package to each tester to install on their device.

Q: How do I set a custom icon and splash screen for my iOS app?

A: Icons can oftentimes be an afterthought during the busy development cycle of an app, but they are required by Apple when you submit your apps. Titanium provides you with default icons (as well as splash screens) for development purposes, but those are just placeholders and you’ll obviously want to add your own imaging before publishing.

Depending on your app type, target platform, and distribution choices, you might need to create many variations of these graphics. Two things you will want to keep in mind when going through this process are the location for your images and pre-rendered icons on iOS (Apple adds the rounded corners and any other effects). Including icons in your iOS IPA file is really simple – you can either create the individual files required for each device OR you can create a single DefaultIcon.png file (that’s 1024 x 1024 pixels in size) and drop this into the root of your project (or the app folder if you’re using the latest version of Alloy). Titanium will take care of taking that icon and creating all the variations for you.

Splash screens are equally important, and add an often necessary context for users that your app is in the process of loading. Typically you can replace the default.png images that are created for you in the iPhone assets folder with the ones of your choice. However, an easier approach and one that’s the default with the apps built with the latest SDKs is to use a Launch Screen Storyboard. This a LaunchLogo.png icon file in the app/assets/iphone folder to display a simple splash screen that works on all devices without any additional effort.

For a complete list of iOS graphic asset requirements, options and instructions, please check out our tables and read more here.

Q: Are there differences in an iOS Simulator and an actual device?

A: Here are some key things to remember when working between iOS Simulators and devices that can trip you up if you’re not careful:

  • Devices are case-sensitive. It’s really easy to make a mistake referencing a file, image, controller in Alloy etc, and have it work without a problem on the simulator, only to find it crashes when deployed to a device. Typically this is because you might have referenced MyImage.png instead of myImage.png or something similar.
  • Push notifications don’t work on simulators. Whilst it can appear to ask for permission, even obtain a device token in some cases, a simulator won’t be able to display push notifications – you’ll have to do this on devices only.

It’s always recommended to test your applications on a real device before distributing to test users or sending to the App Store. In Alloy, there’s some neat conditional checks you can use to test the environment you’re running in. The DEV_ENV variable with return true if the app is running on a simulator OR running with liveview on a device. The ENV_TEST variable will return true if the app is running on a device, and ENV_PRODUCTION will be true if it’s a production build.

You can find out more about these variables (and more of them) here.

Need help to get started with Titanium? Check out our Welcome to Titanium guide for a full overview and our Quick Start guide for fast troubleshooting. For more, check out Titanium Sample Code and our free tutorials. We’ve also compiled Best Practices and Recommendations in case you get stuck.