Over the past week there have been a couple of changes for Apple Developers. One only affects developers while the second also affects customers.

Apple Small Business Developer applications are now open

Applications for Apple's Small Business developer program began on Thursday, December 3rd. If you enroll by December 18th, 2020 at 10:00 am Pacific time you will receive the benefits of the program. To recap, if you earned less than $1m per year in Apple's App Stores you are eligible to have a reduced commission of 15% instead of 30%. If you go above this amount in a year, Apple will receive a 30% commission for all sales after $1 million, as well as the following year. You can read a full-recap here. There have been a couple of additional details provided.

App transfers are not allowed while participating in the program. If you initiate an app transfer after December 31, 2020, or accept a transfer of an app that was initiated after December 31, 2020, you will no longer be eligible to participate in program.

This makes sense to some degree, because typically indie developers are not transferring apps, but that is not always the case. A second clarification on what happens if you enroll after December 18th, is also outlined.

If you’re already a member of the Apple Developer Program and submit your enrollment for the App Store Small Business Program after December 18, 2020, at 10 a.m. PST, your proceeds will be adjusted fifteen (15) days after the end of the fiscal calendar month in which your enrollment is approved. For example, if your enrollment is approved on February 10, 2021, your proceeds are adjusted starting March 14, 2021.

Again, this aspect of it makes sense, but some time is probably needed to make the actual adjustments. There is further information available on Apple's Developer website, including a link to actually enroll. This change will only affect developers, however the next item will affect both developers and their customers.

Family Sharing enabled on in-app purchases

If you are a developer and you have in-app purchases in your apps, you may be able to enable family-sharing on them; should you choose to do so. It is quite common for one family member to make an in-app purchase and want to share that with their other family members. However, until now this has not been possible. To enable family sharing on your in-app purchases, perform the following steps:

1. Log in to App Store Connect.
2. Click on "My Apps" to bring up a list of your applications.
3. Click on the app where you want to enable family sharing of your in-app purchase.
4. On the left-hand side under "In-App Purchases", click on "Manage". A list of available in-app purchases should be appear when the page loads.
5. Click on the in-app purchase that you want to manage.
6. Under the "Family Sharing" section, click on the "Turn On" link. A popup will appear.
7. The popup states "This in-app purchase will be able to be shared by everyone in a family group. NOTE: Once you confirm, you won't be able turn off this feature." Click on "Confirm" to enable family sharing for the in-app purchase .

There are two things to note. First, and most importantly, once you have enabled family sharing for an in-app purchase, it cannot be turned off. Secondly, not all in-app purchases are eligible for family sharing. Only non-consumable in-app purchases and subscriptions are eligible for family sharing. You can learn more on the App Store Connect help page for Family Sharing of In-App Purchases.

Both of these changes are welcome for developers. Customers will be able to benefit by not being required to make multiple purchases and instead can share existing purchases.

When Apple initially released iOS 13 and macOS Catalina, they had anticipated that they had provided developers enough time to comply with some requirements. These are:

• Apps must be built with the iOS 13 SDK, and use a Storyboard for the launch screen
• iPhone apps must support all iPhone screen sizes and iPad apps must support all iPad sizes
• Apple Watch apps need to be built with the watchOS 6 SDK
• Apps that support third-party sign-on services must also support Sign-In With Apple

Initially, Apple had wanted to have these in place by March 31st, 2020. However, due to Covid-19, many developers may not be able to accomplish this in the allotted time. Because of this, Apple has extended the deadline until June 30th, 2020.

If you are a developer, be sure to comply with these changes by June 30th, otherwise your app may get removed from the App Store.

Source: Apple Developer

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.

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.

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.

Implementation

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

Source: Swift.org

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

Over the past couple of weeks there has been some discussion, and consternation, about Apple rejecting, allowing, and then subsequently pulling the HKMap Live app from the Hong Kong App Store. The controversy stems from the fact that the Apple ultimately pulled the app due to information received from the Hong Kong Cybersecurity and Technology Crime Bureau. The information provided to Apple is that the app was being used not only to avoid Police, as the makers of the app intend, but also to target police and other protesters. My thoughts on whether or not Apple should have pulled the app are mixed.

Apple cannot just ignore the will of the Chinese government. This is due to Apple's reliance not only on China for sales, but also because their manufacturing relies heavily on China. China has one of the most advanced and integrated supply chains in the world. China's skill not only with manufacturing but also being able to source the quantities needed by Apple are unparalleled.

One day Apple may be able to reduce their dependence on China, and they are making in-roads into being able to do so, but right now it is not currently something that is feasible. Due to their reliance on China, Apple is limited in how it can challenge their will and authority. This is not limited to just China, but China is one of the largest economies in the world and Apple must comply with all laws, including those in China and the Hong Kong territory.

The whole situation has gotten me to thinking about my own apps and books. In particular, whether or not to continue to have them available in the stores of countries that do not meet with my own personal morals.

Because of this I have come to the decision to remove my apps and books from sale within certain territories. These territories are ones that do not meet my personal moral standards. Which countries I have pulled my apps and books are listed below.

• Bahrain
• China (Mainland)
• Colombia
• Laos
• Qatar
• Russia
• Saudi Arabia
• Tajikistan
• Turmenistan
• Uzbekistan
• Venezuela
• Yemen

If additional countries warrant the removal of my apps and books from sale, or if the countries listed above warrant me allowing the sales of my apps and books to continue, I will add and remove the countries as needed.

I take stances in many different aspects of today's society. These include which stores I will purchase from, which websites I will visit, and which company's products I use (You may be able to guess one of the companies in the last category quite easily). One area where I did not necessarily take a standard, was when it came to where I will sell my creations.

I had physical goods, then it would be less likely that my products would not be available in all countries. This is the case with my paperbacks, since they are only available from Amazon in select markets. Most can be ordered through a book store. Because my products are available digitally, I have always wanted to reach the largest possible audience. Therefore, my books and apps have always been available in all countries. But that is changing. I have decided to take a stance and not provide my apps and books for sale in some countries.

This is a moral stance for me, one that I am able to take because it comprises 0.32% of my app sales ($6.14 over the lifetime of my apps) and 0.075%, or $5.60, of my book sales. Removing the apps and books from sale in these countries will not meaningfully affect my income. This is particularly true since the income from my apps and books is not my primary source of income, but I have decided to take this stance. If you do not agree and decide not to support me by purchasing my apps and books, then that is your decision to make.

There are two debates that will never be solved. The first is VIM vs. Emacs and the second is Tabs vs. Spaces. For the VIM vs. Emacs debate, I use VIM, only because it is the first linux-based editor I learned to use and no, I do not need to look up how to quit out of VIM (it is :q by the way, you can use :wq to write to file and quit). Instead, I would like to focus on the other eternal debate, Tabs versus Spaces. Before I delve too far into the topic, let me share some background.

Day Job

My job title at work is Developer. It has not always been this, but development is what I have been doing during my tenure there. Primarily, I create custom web applications and reports using PHP, HTML5, and CSS. Over the summer I spent some time re-writing some older code that I written. There are a variety of things to think about when making web apps, like following HTML standards, accessibility, alt on images, and the like. One aspect that is often overlooked is how the source code looks when it is viewed in an editor. Many developers overlook this aspect when it comes to web coding. Yes, the primary concern is really making sure the product works and meets standards, yet future maintainability should also be a concern particular when you need to go back and look at some code that you have not looked at in a while. You likely do not want to spend an inordinate amount of time deciphering your unformatted code.

Being able to look at the source code and have it look decent is something that I have been doing for a long time. One way that I achieve this is to line up equals signs. Here is an example of what I mean:

I could just use a single space or tab after the end of a variable name, but the code generally looks better when everything is lined up. Usually there are a number of variables within a particular function, file, or other scope of code. I would always try to line up the equals signs. This usually allows me to know what I am looking at without having to look all around the code.

However, while I was reworking the code, I came to the realization that this is somewhat wasteful. Not necessarily because of the extra keystrokes, which is part of it, but because of the amount of space that the file takes up on the drive. There is another aspect that I was thinking about as well.

Side Thought

While I was re-writing the code, there was a nagging thought in the back of my mind, the size of current webpages. With the proliferation of JavaScript-laden webpages, as well as ubiquitous tracking in general, the size of webpages have significantly increased over the past decade. Web developers often overlook

Tabs versus Spaces

My position is to use tabs whenever possible. The reason I think this is due to the size of the file. Examples are always good, so let me provide one. Say you have a file that is 2 kilobytes in size. It is small, and this file uses tabs throughout where needed. The file size is small, and generally smaller than the size of a cluster on a hard drive or SSD. Now, imagine replacing all of those tabs with four spaces. You have now quadrupled the size of the file from 2 kilobytes to 8 kilobytes. Even with this, the size of the file may still be smaller or just at the size of a single cluster on a disk.

Now, let us extrapolate that. Say for instance you have a 1 megabyte file that uses tabs and you replace each tab with four spaces. The file size has again quadrupled but now it is four megabytes in size. Even if the file is only called once in a while, it is still a rather large file. Let us extrapolate this further. Imagine the file is called 1000 times per day and at 4MB, that is now 4GB worth of bandwidth used. If you are on an internal network that may not be a concern, but on the internet it can become one.

Exceptions

I should clarify, the above example is only meant for interpreted code, not complied code. For the source of compiled code, it may not make a difference. It should also be noted that you could use a strip-whitespace function for some languages, however, depending on the language this may result in the script being misinterpreted.

I know some language style guides indicate what should be used, where most indicate spaces. If I was going to release something as open source and to be used by a wide variety of individuals I would likely follow the style guide of the language, but for personal projects, I will continue to use tabs.

Closing Thoughts

Maybe it is just my thinking, but reducing the overall code size of a project is a good thing, particularly if it is a web-based application. Not only will this save on storage space, but it will also save on the bandwidth consumed by users who are often saddled with a bandwidth cap. While I can understand the need for following a style guide, it is also possible that the time the style guide was written that some considerations were not taken into account. Lastly, do not do what the top image does, that is just wrong and is prone to errors.

There is a minor update available for my apps, wwrite and wwriteLite. This update fixes a situation where the app may have crashed when you clicked on the "Support via Twitter" button.

If you have any issues, bug reports, or any other feedback, be sure to get a hold of me on twitter @waynesworkshop, or through the app.

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.