Apple Developer macOS Swift

Swift Playgrounds for Mac Now Available

In 2014 Apple introduced a new programming language called Swift. Swift took the best of existing programming languages and wrapped it into one. In 2016 Apple introduced a new way to work with Swift, called Swift Playgrounds.

Swift Playgrounds are, as the name implies, areas where you can play with the different aspects of Swift within a single area. Swift Playgrounds was introduced for iOS as an iPad-only app. Swift Playgrounds is no longer an iPad exclusive with the release of Swift Playgrounds on for macOS Catalina.

Swift Playgrounds on macOS is a Catalyst app. This means that it is the same code that is used with the iOS version of Swift Playgrounds. With this, it means that the app is the same as the iOS version, just available on macOS. Now that Swift Playgrounds is available on macOS you are able to use the existing playgrounds that you used on iOS on your Mac and vice versa. Additionally, any changes that you make on either platform will synchronize to the other.

The fact that Swift Playgrounds is on both platforms will allow those who may only have access to Mac and not an iPad the ability to learn how to code using Swift Playgrounds on the Mac. There is a version of Swift Playgrounds available within Xcode, but that does not have all of the same features, like code completion, the tutorials, and connectivity to the bluetooth accessories like Sphero.

If you have ever wanted to learn how to program, Swift Playgrounds is a great tool for doing so and now you can use it on your Mac. You can download Swift Playgrounds for free on the Mac App Store today. It does require macOS 10.15.3 or later.

Swift Playgrounds on macOS

Apple Updates Q2 2020 Guidance

It is not often that Apple updates the guidance that it provides to investors, however there are times when it is necessary. The first time was with Q1 2019 guidance. In that case it was due to a myriad of factors, including lack of sales in China and Emerging Markets and foreign exchange rates.

Apple is revising its guidance again with Q2 2020 numbers. The primary reason for this is due to the COVID-19, or Coronavirus, that has been a problem within Mainland China and that Apple is “experiencing a slower return to normal conditions than we had anticipated.” This means that Apple will not meet their revenue guidance. From Apple:

The first is that worldwide iPhone supply will be temporarily constrained. While our iPhone manufacturing partner sites are located outside the Hubei province — and while all of these facilities have reopened — they are ramping up more slowly than we had anticipated. The health and well-being of every person who helps make these products possible is our paramount priority, and we are working in close consultation with our suppliers and public health experts as this ramp continues. These iPhone supply shortages will temporarily affect revenues worldwide.

The second is that demand for our products within China has been affected. All of our stores in China and many of our partner stores have been closed. Additionally, stores that are open have been operating at reduced hours and with very low customer traffic. We are gradually reopening our retail stores and will continue to do so as steadily and safely as we can. Our corporate offices and contact centers in China are open, and our online stores have remained open throughout. Outside of China, customer demand across our product and service categories has been strong to date and in line with our expectations. The situation is evolving, and we will provide more information during our next earnings call in April. Apple is fundamentally strong, and this disruption to our business is only temporary. Our first priority — now and always — is the health and safety of our employees, supply chain partners, customers and the communities in which we operate. Our profound gratitude is with those on the front lines of confronting this public health emergency.

I think Apple is doing the right thing, from both a fiduciary as well as a humanitarian standpoint. They do have to legally report to the shareholders any changes that will affect their guidance. Regarding the humanitarian side, this is a very contagious virus and the health and safety of Apple’s direct employees as well as the works within the factories that produce their products.

I am sure that Apple, and the world as a whole, would prefer that COVID-19 virus was not an issue, but that is not the world we live in, and we all have to adjust accordingly.

Source: Apple

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 Developer Swift

Apple Introduces Swift Crypto

There are many things that can mark the maturity of a programming language. Things like Application Binary Interface, or ABI, stability, Application Programmer Interface, or API, consistency, the re-working of the language syntax, or the inclusion of a vital feature within the language. It has been five and half years since Apple introduced its own programing language, Swift.

In the years since its introduction Swift has undergone a huge transformation since its initial release. With Swift 3, the entire syntax of the language was redone so that it had a consistent naming and its syntax was significantly shortened. Swift 5 introduced a new Swift-only interface language called SwiftUI. and with Swift 5.1, ABI stability came into existence. One thing that has been missing from Swift has been its own native Cryptographic library. That has now changed.

Swift Crypto

At the dot Swift conference Apple introduced a new feature to the Swift programming language, Swift Crypto. Swift Crypto is an open-source re-implementation of Apple’s objective-c framework CryptoKit. There are a few things that make Swift Crypto a bit different from other cryptographic frameworks.

The first is that Swift Crypto is not built into the Swift language itself. Instead, it is implemented as a Swift Package. This has a couple of added benefits. The first benefit is because it is a Swift Package, it can be independently updated outside of the core Swift language. This means that should a vulnerability be found in the package or its implementation it can be fixed and a new release be made. Similarly, if new algorithms become standard, these too can be implemented without requiring a new version of Swift. Furthermore, this means that if you need to keep on an older version of a language you do not need to sacrifice security.

The second benefit is that this package will work on all of Apple’s platforms, macOS, iOS, tvOS, and watchOS, as well a on Linux. The fact that the package will work on Linux means that both your server side code and client code can use the same cryptographic libraries.


Swift Crypto uses Google’s BoringSSL framework for implementing the cryptographic primitives and therefore does not re-implement these, but only on non-Apple Platforms. If you use Swift Crypto on Apple’s platforms, it defers to CryptoKit. That does not mean that you should not use Swift Crypto within your project though. While it will defer to CryptoKit, using Swift Crypto will provide you a consistent interface across all platforms, which will make your code easier to maintain.

Secure Enclave

Apple’s native CryptoKit APIs implements some interfaces to Apple’s security hardware processor, called Secure Enclave. Because Swift Crypto will work on both Apple’s platforms as well as Linux, results in Swift Crypto not implementing these APIs. Hence, if you need to utilize the Secure Enclave APIs, you will still need to use the CryptoKit APIs to implement these.

Closing Thoughts

The addition of a Swift-native Cryptographic library will make it easier in a couple of ways. First, by allowing the same Swift Package to be used across Apple’s platforms as well as Linux. While Swift Crypto will not implement the Secure Enclave APIs, any implementations made within CryptoKit will also be done within Swift Crypto.

Being a Swift Package, Swift Crypto can be kept up to date with the changing landscape of cryptography independent of relying on a new version of Swift to have any changes implemented.

The addition of Swift Crypto should allow a consistent implementation between server-side code as well as client code making it easier to implement the features, regardless of platform. Swift Crypto does require Swift 5.1 or later and the package is semantically versioned and, as of this writing, is at version 1.0.0. If I need to implement any cryptographic items within my projects, I will likely use Swift Crypto



Jeep Groundhog Day Commercial

Today is Groundhog Day and I always end up watching the movie Groundhog Day around February 2nd. Well, Jeep has created a fantastic commercial that those who have seen the movie may recognize.