Version 4.6.2 of wwriteLite is now available. This is a minor update that fixes two bugs.
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.
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.
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.
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.
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.
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.
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 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.
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.
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:
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.
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:
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:
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.
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.
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.