Covid-19 has become a global pandemic. Many companies, states, and other local governments are taking extraordinary steps to help curb the infection rate. The state of Illinois is going to great lengths by closing all schools for two weeks. Many companies are cancelling large gathering and having their staff work from home for extended periods of time. Apple is no exception. To quote Apple

We will be closing all of our retail stores outside of Greater China until March 27. We are committed to providing exceptional service to our customers.

The note from Apple Chief Executive Officer Tim Cook continues:

In all of our offices, we are moving to flexible work arrangements worldwide outside of Greater China. That means team members should work remotely if their job allows, and those whose work requires them to be on site should follow guidance to maximize interpersonal space. Extensive, deep cleaning will continue at all sites. In all our offices, we are rolling out new health screenings and temperature checks.

All of our hourly workers will continue to receive pay in alignment with business as usual operations. We have expanded our leave policies to accommodate personal or family health circumstances created by COVID-19 — including recovering from an illness, caring for a sick loved one, mandatory quarantining, or childcare challenges due to school closures.

Lastly,

Apple’s committed donations to the global COVID-19 response — both to help treat those who are sick and to help lessen the economic and community impacts of the pandemic — today reached $15 million worldwide.

We’re also announcing that we are matching our employee donations two-to-one to support COVID-19 response efforts locally, nationally and internationally.

Apple closing its stores is no real surprise. They did the same thing in China during the height of its infection, so it would make sense to do the same in other parts of the world. It is also good to see Apple donating money to help those affected by the virus, as well as continuing to pay hourly workers.

Source: Apple

It is likely that you are aware that there is an international pandemic known as Covid-19. The highly transmissible virus is a problem and in order to minimize the spread, it is best to avoid large gatherings where transmission is possible.

In order to avoid having anyone contract the virus with 5,000 developers gathering in one place, Apple is changing the format of this year's WorldWide Developer Conference (WWDC) to an online format. For a vast majority of Apple's 23 million registered developers experience Apple's WWDC in an online-only format. In fact, the number of developer who can actually attend WWDC is 0.022% of all developers.

Apple will still hold a keynote and online sessions. To quote Phil Schiller, Senior Vice President of Marketing:

“The current health situation has required that we create a new WWDC 2020 format that delivers a full program with an online keynote and sessions, offering a great learning experience for our entire developer community, all around the world. We will be sharing all of the details in the weeks ahead.”

One of the downsides to moving to an online format is the fact that San Jose, where WWDC has been held the last few years, will lose out on a significant amount of revenue because of the conference. In order to help San Jose, Apple is going to provide $1 million to San Jose organizations to help offset the loss.

My prediction is that next year's WWDC will return to an in-person conference, although some of the changes made this year will still be incorporated into next year's conference. I hope to be able to watch the keynote in June, but either way I will be writing a post about what Apple announces. It will be interesting to see how this year's WWDC goes.

You can keep up to date with what Apple announces by "email, in the Apple Developer app and on the Apple Developer website".

Source: Apple

Earlier this week Apple adjusted some of its App Store Guidelines. There have been some changes surrounding prompting for App Store reviews, Sign-in With Apple, building against the iOS 13 SDK, Push Notifications, and certain app categories. The latter two are the ones I want to focus on.

Ads

One area where users often complain is in regards to the push notifications that they receive from apps. While you can control whether or not you receive push notifications from an app, it is often not possible to specify the type of notifications that you receive.

The ability for some apps to be able to advertise to their users is paramount. Often this is done via in-app ads. However, other times this is done via push notifications. This can not only detract from a user's overall experience, it goes against Apple's App Store guidelines. The guidelines have now been modified

Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app’s UI, and you provide a method in your app for a user to opt out from receiving such messages.

This is a welcome change for both users and app developers. App developers will be able to advertise to users who actually choose to hear about new products and possible services. If you have an app that users enjoy and you have a new offering they will likely be more receptive to the new product.

My concern about this rule is that it will not be enforced as strictly that it should be. It is my opinion that Apple should give an app maybe two or three chances before pulling the app from the store. Repeatedly violating this app should result in a permanent ban of the app, if not the developer account. This would show app developers that Apple is serious about enforcing the rule.

There is another change that I think might have another angle that most would expect.

Dating Apps

Section 4.3 of the App Store Guidelines states:

Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, fortune telling, dating, and Kama Sutra apps, etc. already. We will reject these apps unless they provide a unique, high-quality experience. Spamming the store may lead to your removal from the Developer Program.

The first few apps: fart, burp, flashlight, and fortune telling apps are very simple and easy to make and really do not provide much value. Dating apps on the other hand can provide new and innovative experiences. However, many of them are just simply slightly tweaked takes on the "swipe left or right".

I think there is another aspect to dating apps that most might not think about. For dating apps you provide a significant amount of information like location, photos, interests and the like. This information, when linked to email address, can easily identify someone and this information can be provided to third-parties which then can be used to target you. Additionally, if the information gets into the hands of a nefarious entity, the information could be used against you.

I think this is why there is the line "unless they provide a unique, high-quality experience". I interpret this to mean that if a company like Twitter or Facebook were to want to release a dating app, it would likely be approved, but if a company called "ACME Dating app" were to try and release a dating app, it likely would be rejected.

Closing Thoughts

The guidelines that govern the App Store are adjusted from time to time to reflect changes in society and trends in the App Store. The adjustments that Apple has made are changes that could improve the experience for everyone, provided that they enforce the changes like advertising within Push Notifications. Ultimately, only time will tell if the changes will ultimately help or hinder the experience of users.

Source: Apple, 9to5Mac

Version 4.6.2 of wwriteLite is now available. This is a minor update that fixes two bugs.

1. This version fixes a crash that would occur when tapping on an ad description.
2. The second item that was fixed is the inability to perform an action on a file if ads were not disabled.

wwriteLite 4.6.2 is now available and is free.

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.

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

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 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.

When technology "just works" it is absolutely fantastic. It can allow us to do things that we never thought possible. Technology can provide us interactions and efficiencies that were mere ideas only a short time ago. However, when technology goes awry, it can be a complete disaster. This is exhibited with my ongoing iCloud issues.

The Issue

The issue I am having with iCloud is that I cannot upload any files to iCloud Drive. When I do, it just sits and pretends it will upload the files, but it does not. The same goes with downloading files from iCloud Drive; no files can be downloaded. This renders iCloud entirely useless.

Now, this may not be a big issue if I only used iCloud randomly and sporadically; but that is not the case. I use Apple's "Desktop & Documents folders" syncing feature, which allows any files I create in m "Documents" or "Desktop" folders to synchronize to all of my Macs and iCloud. This includes being able to access the files from within any application or on my iOS devices. Due the inability to upload or download any files to iCloud, these features are entirely broken.

Backstory

This actually began on December 1oth, 2019 after I upgraded my iMac to macOS Catalina 10.15.2. My MacBook Pro is usually on the developer version of macOS and it did not exhibit any of this behavior and was synchronizing files without a hitch. At first I thought it might have just been a fluke and that iCloud needed time to resynchronize everything. After a few days of not being able to synchronize anything, I contacted Apple Support.

Apple Support

When I contacted Apple support I was connected with a tech support person who attempted to help me. We did some testing, which included trying to upload files to iCloud on all of my devices and on different networks, rebooting the device, but none of these steps had any effect.

Since the first tech support person I contacted was not able to find a fix, I was transferred to a specialist. Over the course of a couple weeks we did various things, including:

• Creating a test file and uploading it (does not work)
• Creating a new account and trying to upload a file (does not work)
• Trying to find any offending files that were not uploading and remove them (had no effect)
• Uploading files via the web interface (which did and does still work)
• Creating a file at a specific time and then gathering the logging information for 24 hours

After all of this testing and nothing working, the issue was sent to Engineering. Engineering came back with some questions and requests, and required screenshots on iOS of the issue. One of the things they requested was to install a configuration profile to gather some data. The log that was uploaded ended up being well over a gigabyte in size; and that was when it was compressed.

Partial Fix

Due to the complete hassle this has been I began looking for a fix on my own. As with any problem, it is best to search google. I came up with this solution from stackexchange.com. The following commands were entered into terminal:

killall bird
cd ~/Library/Application\ Support
rm -rf CloudDocs

These steps will do the following:

1. Stop the "bird" service. The "bird" service is the service that controls uploading and downloading data to and from iCloud Drive.
2. Change directories to the local user Application Support directory under the "Library" directory.
3. Remove all of the cached files for iCloud.

When these have been done, you need to restart the computer, just to be on the safe side. When I did this on my MacBook Pro, it began downloading the file list in iCloud Drive. Once this was done, the biggest portion of the work began. That work is comparing the local copies of the files with the files that are stored in iCloud Drive. The length of time is depending on the number of locally stored files that you have.

Due to the amount of information I had on my MacBook Pro this ended up taking several hours. But once it was finished I tested uploading a file to iCloud Drive and it worked. I waited a couple of days to make sure things still worked. Upon verification, I then performed the same steps on my iMac and it produced the same results, albeit the amount of time it took on my iMac was a bit longer due to having more files on my iMac.

My iOS devices were another matter entirely. Because you do not have access to terminal on iOS, you cannot perform the same actions. The only steps you can do on iOS are:

1. Open the Settings app.
2. Click on your Name at the top to open up the iCloud settings.
3. Tap on "iCloud" to open iCloud options.
4. Scroll down to "iCloud".
5. Tap on iCloud Drive toggle switch to disable it. A popup may appear.
6. Click on "Delete from iPhone" to confirm any documents that are not synchronized will be deleted. This will turn off iCloud Drive and delete any locally saved documents.
7. Reboot the iOS device.
8. Plug the iOS device into power.

You can then restart your device and perform the same steps to turn iCloud Drive back on. When I did this, it did not seem to have any effect, at first. After about 45 minutes the files that are stored in iCloud Drive populated. Unlike on macOS, I do not think any of the downloaded files that I had remained on the device. One last thing to keep in mind is that when you disable iCloud Drive on an iPhone it will also disable the Wallet app, because the Wallet app depends on iCloud Drive to function properly. So you will want to re-enable Wallet on your device as well. Disabling iCloud Drive will not remove your cards, so I am not sure what function requires iCloud Drive within the Wallet app.

Once I saw the list of files, I then created a test folder and verified that it would indeed upload and I could see it on my other devices. So, this seemed to work.

It may not strictly be necessary to plug the iOS device into power, but it cannot hurt because when an iOS device is connected to power, additional processes will run that may not run when the device is on power and this may ultimately speed up the population of the iCloud Drive files.

Possible Root Cause

While I cannot fully know, I think I have determined the cause of the issue. When it comes to any app, you are likely to have a "state" for something. In the case of Files, the "source of truth" is iCloud. I think that the synchronization information on my iMac somehow got corrupted and that corrupted information propagated to all of my devices. The only way to get things back into place was to erase the local cache and re-download all of the data from the server.

Closing Thoughts

As of this writing, everything seems to be working. I am somewhat disappointed that Apple could not find a solution, and I was left to find a solution on my own. Also, at the moment, my issue is still in Engineering, and I do not expect to hear back from my support representative about a fix for the issue. I am glad I was able to find a solution to get things back on track, but these types of things need to be handled by Apple in a much faster manner than they are now.

One way to mitigate this from happen would be for Apple to create some sort of automated testing that occurs on each device where it attempts to create a file and upload it to iCloud. If this does not happen within a period of time, say 24 hours, send a push notification that will trigger the resetting of the iCloud cache information stored on the device. This type of solution would be able to mitigate, if not eliminate, these types of issue because it would end up being proactive and not wait for the user to notice that something is wrong and attempt to find a solution with the help of Apple. I completely get that I may have just been a "lucky" one to run into this bug and it may only be affecting a small percentage of users. However, when you have 1.5 billion active devices, even one tenth of one percent is still 1.5 million people. Even if the percentage is much smaller, this type of solution could go a long way to improving user experience.