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

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

Categories
Apple Developer

Upcoming Changes for Apple Developers

When you sign up to be an Apple Developer one of the things that you do is agree to abide by App Store Review Guidelines. These guidelines change from time to time depending on technology, the needs of developers, and the limitations that Apple wants/needs to apply.

Last June the guidelines were modified and two additions were made. These are regarding “HTML5 Apps” and “Updates in the Kids Category”. There are some changes for both that will go into effect on March 3rd, 2020. Let us look at each of the changes.

HTML 5 Apps

Before there were native apps on iOS there were HTML5 apps, which was referred to as a “Sweet Solution”. While this worked, it was not nearly as elegant as using a native application. A majority of applications in use today are built entirely with their native SDKs and do not require any external code. There are some apps that may require some code that is downloaded from another server. This is possible with Apple’s platforms. However, there are some limitations regarding the code that can be downloaded.

Specifically, HTML5 apps cannot contain or run code that provides access to real money gaming, lotteries, or charitable donations.

Apps For Kids

The next area to discuss is Apps for Kids. Any app that is within the “Kids” category, which means that it is intended to be used by kids. Due to the nature of these apps, there are some restrictions that developers need to comply with.

“Apps published on the App Store must protect children’s data and provide only age-appropriate content. Apps must also require a parental gate in order to link out of the app, request permissions, or present purchasing opportunities. It’s critical that apps do not transmit personally identifiable information or device information to third parties, and that advertisements are human-reviewed for age appropriateness in order to be displayed.”

Besides being conscious of children’s data, in some places this is necessary to comply with local laws.

Closing Thoughts

Developers have to keep up with the changes not only in tools and techniques, but also the changing landscape of building apps for Apple’s platforms. One of those areas is complying with the App Store Review Guidelines. What may have been accepted previously, may no longer be accepted. If you are going to be uploading a new version of your application anytime after March 3rd, 2020, you will want to comply with the new rules; especially the one regarding privacy of kids’ data. It would not be surprising if Apple begins outright rejecting apps that do not comply with protecting the data of kids starting on March 3rd.

Source: Apple, Apple

Categories
Apps Books Developer Me

Taking a Stance with my Apps and Books

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.

Categories
Developer Thoughts

My Thoughts on Tabs versus Spaces

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:

$short1           = "short";
$longvariablename = "long";

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.