Apple Apple Watch watchOS

Developer Changes for In-App Purchases

When Apple introduced the ability to publish apps to the iOS App Store in 2008, it was a very different landscape from what we have now. Back then you had either apps that you published for free or ones that were paid up front. Now, free apps are far more common than paid up-front apps.

In 2010, Apple introduced a new product, the iPad, which allowed for more opportunities within the App Store. With the introduction of the iPad you had two options, create a universal app, one that would work on both the iPhone and the iPad, or create two separate apps; one built for each platform.

While the possibility to build two distinct apps remained for a while, the introduction of the Apple Watch and the Apple TV have made the idea of creating distinct apps for each platform a bit harder to accomplish. The interfaces should be tailored for each platform, but the app itself would likely be shared amongst iOS and iPadOS.

Last year with the introduction of macOS Catalina, there was a new way to distribute your existing iOS apps, to macOS, through a project called Catalyst.

With free apps there are a number of different strategies for supporting free apps. These can be, ad-based, subscriptions, or in-app purchase. It has become more and more common for the latter two of these to be used. With in-app purchases, if you built an application for both iOS and macOS, using Catalyst or native frameworks, you would have to create two different in-app purchases, because they could not be shared between the platforms.

With the introduction of iOS 13.4 and macOS Catalina 10.15.4 you will

be allowing customers to enjoy your app and in‑app purchases across platforms by purchasing only once. You can choose to create a new app for these platforms using a single app record in App Store Connect or add platforms to your existing app record.

This is a huge change for the App Store and the distribution of apps in general. Users have been requesting the ability to purchase an app once and have it work on all of their devices. While this works for users, this can have some implications for developers.

Developer Implications

While the option to distribute a single application to all of the platforms is optional, it is likely something that users will quickly come to expect from developers. Yes, there are tools like Catalyst for macOS, it is still not at its full maturity in terms of having iOS apps ported to the Mac look and behave like native macOS apps that use AppKit.

This can have some ramifications for the developer. The first being that this can easily cut into profits for a developer. For larger companies, this may not be a big problem, but for the smaller independent developers this can have a huge impact.

With the pressure to make your application available on all platforms, and in-app purchases being good across all platforms, this will likely reduce the income for developers.

There are some developers who have wanted to have universal in-app purchases available because they want their users to be able to have the same experience on all platforms, plus users also question why they have to make the same purchase on multiple platforms. Therefore, this will be a great addition for both users and developers.

In-App Purchases on watchOS

Starting with watchOS 6.2, developers will be able to provide in-app purchases directly from watchOS. This will have a huge benefit to the watchOS platform as developers will not need to have users use their paired iPhone to perform in-app purchases, but instead have it possible to purchase them directly on the Apple Watch. This should provide a better experience for Apple Watch users and the in-app purchase workflow.

Closing Thoughts

While the addition of universal apps as well as universal in-app purchase will create a better experience for users, it could have some ramifications for developers in that they will be expected to support universal in-app purchase, which developers may want to do, as well as supporting universal app purchase, which may reduce their income.

I cannot say that this is not altogether unexpected, because it is something that both users and developers have been asking for for a while. It may take some time for applications to come to support universal in-app purchases as well as universal app purchases. This should be available starting with iOS 13.4, macOS 10.15.,4, tvOS 13.4, and watchOS 6.2.


Apple Updates its WWDC App

Today Apple announced that they are updating their WWDC app. There are three major changes. These are the name, a new WWDC tab, and in-app purchasing. Let us start with the name.

The WWDC app is now known as the Apple Developer app. One can This app’s name is definitely more befitting given the next feature, the WWDC tab.

The WWDC tab is a new tab that encompasses what was previously the entire WWDC app. This includes WWDC schedules, your favorites, lab schedules, and WWDC sessions.

The last new feature is the ability to enroll in the Apple developer from right within the app. This is done using an auto-renewing subscription within the app. Initially, the subscription feature is only available within the United States, but will be rolling out to more countries over time. Apple does have a step-by-step tutorial on how to enroll using the app.

if you already have an account you can log in. The ability to be able to enroll in an Apple Developer account will make it much simpler for developers to be able to enroll in the Apple developer program, without needing to go through the Apple developer site.

Hopefully, this is only the start to new features being added to the Developer app.

Source Apple Developer

Apple iOS macOS

Apple to Require Two Factor Authentication for Developers

Two Factor authentication on a Mac and verification on an iPhone

Today Apple sent out an email to developers about the security of their accounts. The emails states:

In an effort to keep your account more secure, two-factor authentication will be required to sign in to your Apple Developer account and Certificates, Identifiers & Profiles starting February 27, 2019. This extra layer of security for your Apple ID helps ensure that you’re the only person who can access your account. If you haven’t already enabled two-factor authentication for your Apple ID, please learn more and update your security settings. If you have any questions, contact us. Best regards, Apple Developer Relations

There are a few possible reasons for this. The first is, as the email states, to help secure developer accounts. By enabling the two-factor authentication, particularly for Certificates, Identifiers, and Profiles cannot be added by unauthorized users.

This will have some downsides though. By requiring two-factor authentication, only ten devices will be able to receive the two factor authentication codes. For most individual users, this will not be a problem. Five of these trusted devices can be Macs and five of these can be iOS devices.

I contacted Apple Support to verify the number, and it is indeed ten trusted devices that can be associated with an Apple ID.

For larger development groups who may need to allow more than one user to login to the Certificates, you will likely need add a user who has access to the Developer Resources.

If you have not already enabled two-factor authentication on your Apple Developer account, you will want to review the two-factor authentication support page to be sure that you have a way to recover your account, if needed.

Apple Developer

Apple Entrepreneur Camp

Apple has announced a major initiative related to developers, and specifically for an under represented group of developers. When you look at the overall genetic makeup of developers, you may have noticed that there is a disproportionate number of males as developers, as compared to women. Apple has begun an initiative to help correct this imbalance. They call it their Entrepreneur Camp. The Apple Entrepreneur Camp is designed for organizations that are founded and led by women.

There will be four two-week camps run over the course of the next year, these will take place during one of these times:

January 28–February 8, 2019
April 1–12, 2019
July 22–August 2, 2019
October 14–25, 2019

There are some requirements before applying. These requirements are:

  • The organization must have a woman founder, co-founder, or CEO;
  • The organization must have a woman developer proficient in Swift or Objective-C
  • The organization must have a developed app or functional build created for any platform that you can demo live.

Additionally, the applicant must have the following requirements:

  • You must be 18 years of age or older and proficient in English.
  • The woman founder, co-founder, or CEO, the woman developer, and another employee (if applicable) must be 18 years of age or older, proficient in English, and able to attend together for the entire two-week lab.
  • Attendees must be able to bring their own laptop to work on their code in the lab. After you have applied, and if you are accepted, you will be in a two-week lab.
  • If you are a woman who has founded you can learn about all of the details at Apple’s Entrepreneur Camp website.

Per Apple’s site,

Apple Entrepreneur Camp consists of an immersive technology lab, as well as mentorship, education, and support. Selected organizations receive:

  • One-on-one code-level guidance from Apple engineers at a two-week technology lab in Cupertino, California.
    Ongoing support from an Apple Developer representative for at least one year.
  • One year of membership in the Apple Developer Program.
  • Up to two tickets to WWDC for the woman* founder, co-founder, or CEO and woman developer.
  • Access to the Apple Entrepreneur Camp alumni network, a world-class group of inspiring and ambitious senior women leaders.

If you are a woman, or part of a woman-led development company, it would behove you to apply for the Entrepreneur Camp. It is great to see Apple putting so much time and effort into help woman-led companies with mentoring as well as tickets to the next World Wide Developer’s Conference.

You can read all about the camp at Apple’s Entrepreneur Camp website. Applications are open now.

Apple iPhone

iPhone X Review: Developer Considerations

Fifth in my look at the iPhone X we will tackle an area which will not be prudent to everyone, but may be of some interest to many. That topic is what developers need to look at when it comes to their applications on iPhone X.

The iPhone X represents a number of changes, an OLED screen with High Dynamic Range (HDR) support, improved camera, significantly improved processor, and Face ID, just to name a few. Many of these new features require some thought from developers to be able to have the best iPhone X experience for your users. If you have been keeping your application up to date, there may only be a few tweaks that need to be done to fully accommodate the iPhone X. Let us start with items revolving around the screen.


The iPhone X has an all new 5.8 Super Retina HD screen. This screen is an OLED based screen with a resolution of 2436 pixels tall by 1125 wide with 458 pixels per inch. This means that it has a true 3x screen due to the width being 375 points, and the height being 812 points.

This 3x screen means that developers may need to provide assets at true 3x resolution. It was possible to provide almost 3x resolution assets before since the Plus-sized iPhones were scale down any 3x resolution assets to appropriately fit the screen.

It is not likely that many developers would have not had true 3x resolution assets, but in case you did not, it is important to do so now. Along with this, the iPhone X is its own distinct screen size. Throughout the iPhone’s history there have been a total of six different screen resolutions. These have been:

  • 320 pixels by 480 pixels
  • 640 pixels by 960 pixels
  • 640 pixels by 1136 pixels
  • 750 pixels by 1334 pixels
  • 1080 pixels by 1920 pixels
  • 1136 pixels by 2436 pixels

If you are planning on supporting all of the currently supported devices, you will need to support the last four screen resolutions. Since the iPhone X is quite a bit taller, 216 pixels to be exact, you will need to make sure that your assets support the proper aspect ratios in order to be sure that everything appears correctly on each different iPhone model. There is one thing somewhat related to the screen.

Dark Modes

Each user of any application is unique. While you will never be able to please everyone, there is something that you can do to help a segment of your user base. Some users enjoy customizing the way that things look and for some of these users prefer a darker screen. This could be due to eye issues, or just because these themes are more visually appealing to them. For whatever the reason, it may help expand your user base to include a darker theme. The iPhone X may just give you the impetus to creating one within your application.

With the iPhone X being OLED, burn-in may become an issue over time. Even though Apple has done many things to help minimize burn-in, there is one thing that app developers can do to help; implement a dark mode within your app. With OLED, pixels are only turned on when the color is anything other than black. This means that if your application has a dark mode built-in you can help save a user’s screen. Another side benefit of this is that you can also help save battery life for users since the iPhone X will not need to turn on the super dark pixels. If you do not have a dark mode, it may be a good time to start implementing one, you never know it may just help expand your user base.

Face ID

Starting with the iPhone 5s, Apple has included a biiometric authentication mechanism with Touch ID. Touch ID has allowed for convenience when needing to unlock your iOS device or enter in a password. In order for developers to access the Touch ID sensor, Apple created the LocalAuthentication Framework.

The LocalAuthentication Framework provides two return values, a Boolean for the success or failure, and an NSError object, so you can determine the actual error that has occurred. That is all that you, as the developer receive. Given that the LocalAuthentication framework handles the actual authentication and determines which authentication mechanism to use, there is not much that a developer has to do.

The approach of only providing a success or failure, as well as an error, makes the LocalAuthentication framework infinitely scalable, from a developer’s point of view, and reduces the need for complex code. Ultimately what this means for developers is that they have minimal work to do to support Face ID on the iPhone X. In fact the only work that needs to be done is updating strings to refer to Face ID instead of Touch ID, when on an iPhone X. There are no other code changes necessary in order to support Face ID. If a developer does not have time to update their application right away, their application should continue to work, just with the wrong text showing on the iPhone X.

The Notch

The iPhone X brings a new wrinkle for developers, the notch at the top of the screen. The notch houses the True Depth Camera sensor. The notch actually protrudes into the screen and creates two areas that cannot really be used for anything. If a developer has decided to hide the status bar, there could potentially be option available for usage. However, for most developers they do not do this and will need to accommodate a bit within their application.

Apple has indicated that developers should “embrace the notch”. This means that they should not attempt to hide it with black bars. Apple made this decision, not only because it would create a lopsided application, and it would, but also because iOS 11 on the iPhone X utilizes the areas to the left and right of the True Depth Camera are where users access Notification Center, on the left, as well as Control Center, on the right.

If your application is using standard UIKit elements, those elements should automatically extend up to the notch and if you have any colors applied, those should also extend to the top as well. If you do have custom controls, you will need to extend your colors up to the status bar, to provide a more consistent look and feel to your application. One aspect that is new to iOS 11 directly relates to the iPhone X and that aspect is Safe Areas.

Safe Areas

Due to the notch it is important for developers to be able to know just how their applications will function. Until the iPhone X, if a developer chose to support all orientations, they could be reasonably reassured the they would only have two potential layouts to deal with, one in portrait orientation and one in landscape orientation. The iPhone X adds a bit of complexity to this arrangement.

One of the most important aspect to any application is the content. In order to provide developers with the confidence they need when building their apps, Apple introduced a new concept with iOS 11 called “Safe Areas”. Safe Areas, are just as they sound, they are areas where it is safe to put content.

Safe Area Guides are the actual term used to describe these areas. Safe Area Guides can be used on a controller by controller basis. Safe Areas will allow your content to stay within proper areas, not just on the iPhone X, but across all iOS devices. You can choose to allow some aspects of your interface to extend beyond the safe areas if it is appropriate to your application.

A peripheral item that developers need to be aware of, that relates to Safe Areas, is the new home indicator. The home indicator occupies a small portion of the bottom of the screen and automatically adjusts based on the background color. The home indicator will provide a significant amount of contrast so that it is always visible.

What this means for developers is that any controls need to be above the home button area. The area itself is not very large, but it is present. It is important to allow users to interact with this area. Safe Area Guides will allow developers to more easily determine where their application’s content will be shown, without having to worry about customizing each interface differently just for the iPhone X.


If you have an iOS application and you have not yet updated it to support the iPhone X, it may be worth your while to do so. If you do not your app will have black bars above and below the primary content of your app. This is because Apple cannot accurately determine how best to show your application. Therefore, they will present it using a compact size class, with a resolution of 375 points wide and 667 points of height, or 1125 pixels by approximately 2000 pixels.

While it will take some time to adapt your applications to support the iPhone X doing so will allow your application look like it belongs on the iPhone X and not like it belongs on an older iOS device. For many users. having a letterboxes application may result in them abandoning that application in favor of another one that is more native to the iPhone X.

Closing Thoughts

The notch on the iPhone X is the biggest impediment for many developers to update their applications. This is particularly true for full screen applications and games. This is due not only to the notch itself and the work that needs to be done but also because their assets may not be able to scale properly due to the new aspect ratio.

Even though it may take some work on a developers’ part, to update their applications for the iPhone X, in the long run it will be well worth the effort, primarily because the iPhone X form factor is not likely to be a one-off model. Additionally, having an application that looks like it belongs on the iPhone X will not only be better not only for users, but also for developers as it will mean less work in the long run. Next let us turn to another new feature, one that is not exclusive to the iPhone X, but is also present on the iPhone 8 and iPhone 8 Plus; Wireless Charging.