Apple Developer macOS Swift

Swift Playgrounds for Mac Now Available

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

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

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

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

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

Swift Playgrounds on macOS
Apple macOS

macOS Catalina Profile Manager and Other Websites

Each release of macOS has the possibility of changing things and macOS Catalina is no different. There are numerous change with macOS Catalina. I have written an entire book about all of the changes. I use my iMac for developing websites and testing out ideas.

Another thing I use my iMac for is testing out Apple’s Profile Manager service, which is available through the macOS Server app. With macOS Mojave I was able to create a website on a different port. This took a bit of tweaking and configuring of Apache. This was outlined in a post that I wrote last year.

It looks like the initial release of macOS Catalina has actually broken the ability for this to work. Here is the scenario.


After I upgraded macOS to Catalina and then upgraded the, the ability for me to run a website on a different port, at the same time no longer works. If Server is configured, it will start before the Apache service does, and it will utilize ports 443 and 80.

If I stop both Apache and Profile Manager and then start Apache, the configuration works. However, if I start Profile Manager and then Apache, the website would never load. It is not merely a configuration issue, as the site works when only Apache is loaded.

Additionally, if I go to Terminal and type in “netstat -an | grep 8080”, it would return nothing. In case you are wondering, this command will filter the contents of the “netstat -an” command for any lines that have 8080. This would come up blank, which means that the service is not up and running.

The Fix

I spent approximately 4 hours trying to figure out a workaround, but to no avail. When I began writing this post, I did not have a solution for this, but during the writing an idea came to me. Since Server is able to successfully work, why not edit the server’s website configuration and just use it to host the additional sites I need.

This is exactly what I ended up doing. The files for the Server app are located in /Library/Server/Web/Config. Here there are two folders “apache2” and “proxy”. Your first thought might be that you need to modify those under “apache2”. However, the actual file that you want to modify is under the “proxy” folder. Specifically, the “apache_serviceproxy.conf” file.

Here is the configuration that I used.

# Custom Configuration - 8080 / PHP

Listen 8080
LoadModule php7_module libexec/apache2/

<IfModule php7_module>
	AddType application/x-httpd-php .php
	AddType application/x-httpd-php-source .phps

	<IfModule dir_module>
		DirectoryIndex index.html index.php

<VirtualHost *:8080>
    ProxyPreserveHost On
    SetEnv proxy-chain-auth on
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"
    RequestHeader unset Proxy early

<IfModule mod_ssl.c>
    SSLEngine On
    SSLCertificateFile "/etc/certificates/${CERT_ID}.cert.pem"
    SSLCertificateKeyFile "/etc/certificates/${CERT_ID}.key.pem"
    SSLCertificateChainFile "/etc/certificates/${CERT_ID}.chain.pem"
    SSLHonorCipherOrder On
    SSLCipherSuite "HIGH:MEDIUM:!MD5:!RC4:!3DES"
    SSLProtocol -all +TLSv1.2
    SSLProxyEngine On
    SSLProxyProtocol -all +TLSv1.2
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off

    DocumentRoot "/usr/local/website"
    ErrorLog "/private/var/log/apache2/website-error_log"
    CustomLog "/private/var/log/apache2/website-access_log" common


Let me break down what this code does, in order.

  • Indicates to listen on port 8080
  • Load the PHP 7 module
  • Set PHP to be usable by adding extensions to apache
  • Configure the VirtualHost
  • Within the VirtualHost, configure SSL support

There is one section I want to call out specifically within the VirtualHost 8080 configuration. The three lines are:

SSLCertificateFile “/etc/certificates/${CERT_ID}.cert.pem”
SSLCertificateKeyFile “/etc/certificates/${CERT_ID}.key.pem”
SSLCertificateChainFile “/etc/certificates/${CERT_ID}.chain.pem”

I copied and pasted these three lines from the VirtualHost configuration earlier in the file. These actually have a benefit as they will use any SSL certificate that you have configured within the Server app. This means that you will not need to update certificate information in multiple places and instead can update it through the Server app and have it work for all of your sites. This should be an improvement for me since I had to manually configure SSL with apache under macOS Mojave.

Possible Drawback

There is one possible drawback from using this configuration. The drawback is that your configuration could get wiped out by a future update to macOS Server. Because of this, it is a good idea to have a backup of your configuration saved once you get it working. Additionally, you should save a backup outside of the Server Web configuration path, just to be on the safe side.

Closing Thoughts

While it may be a pain to have to use modify the Server’s configuration to have multiple websites, but it is better than not having ti work at all. Before you make any changes, it is always a good idea to have a backup of any configuration files before making any configuration changes.

Apple macOS

New Notarization requirements for macOS 10.14.5

At the 2018 Apple World Wide Developer Conference, a new feature of macOS was unveiled, called Notarization. To quote my macOS Mojave for Users, Administrators, and Developers book:

The concept of Notarized apps mimics the real-world concept of a notary. A notary witnesses the fact that a document has been signed by someone, or multiple parties. zed apps use a notary service that is hosted by Apple that verifies that the application is indeed signed by the developer.

The Notary service will also perform some additional checks on the application. These include security checks that verify the application is doing what it indicates as well as the check for private API usage, similar to Mac App Store apps. However, it should be noted that using the Notary Service is not the same as app review. These checks are merely security related and are only performed to notarize your application.

At the announcement of Notarization, Apple announced that Notarization would be available for developers in the summer of 2018, but would be required for all apps in a “future release”. With the release of macOS Mojave 10.14.5 there has been a step towards notarization being required, but this is just for some apps, not all apps. You will need to notarize your apps if the following applies:

  1. If you are a developer who is creating a Developer ID for the first time.
  2. If you are creating a new kernel extension.
  3. You are updating a kernel extension

Notarization is a security mechanism, not an App Store review. Instead, it is a way of being able to assure that malicious code cannot be injected into your app. Notarizing a macOS app provides more than just peace of mind for end users, but also for you as the developer. One of the additional benefits of Notarization is that the Notarization service will keep an audit trail of each release version of your app. Should the worst occur and your private signing key get compromised, and malicious software be released, you can work with Apple to revoke those apps that you did not authorize and then release a new version of your app.

These are just some first steps in requiring notarization. It would not surprise me if notarization will be required for all apps starting with the next release of macOS, macOS 10.15. This is even hinted at by Apple’s own page:

Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.

The phrase “In a future release” most likely means with the next major release, macOS 10.15. Notarization, while it may seem inconvenient, the process can easily integrate into your workflow and will protect everyone involved. I am sure many developers will not like the fact that they will have to notarize apps, but ultimately it will make things better in the long run.

Source: Apple developer site.

Apple iOS macOS

Apple to Require Two Factor Authentication for Developers

Two Factor authentication on a Mac and verification on an iPhone

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.

Apple macOS

macOS Mojave and Websites

Back in February, Apple announced some major changes to the fall release of macOS Server. One of the changes that they indicated was that many of the services would no longer be included in macOS Server. At the same time, some services would still be present but the user interface elements would be removed. One of the services that would no longer have a user interface is Websites.

macOS Server is used by many, including myself, as a development environment. Besides developers, there are also some companies that need to use Apple’s Profile Manager service, but they also need to use host an internal site, and they need to do all of this on the same machine. If you were running macOS Server running on High Sierra, this scenario was easy to setup and maintain. The same scenario is still possible on macOS Mojave, but it is not as easy. It will take some let us look at how to do this.

macOS bundles in a web server, the one chosen is apache. On macOS Mojave, it is version 2.4.34. This is the latest, as of this writing. The installation of apache is not any different than one you would install on other variations of Linux, which is a good. Even though apache is standard, there are some modifications that are made to accommodate the ability to use of other web-based services, and in particular Apple’s Profile Manager.

Default Configuration

Even under macOS Mojave with installed, there is a default configuration available. You can use this for your configuration, if you so choose. The default location for files is “/Library/WebServer/Documents/”. You can use this for configuration, the default alternative port is 8080. If this is all you need, then you can start putting files in the path above and navigate to, or another IP address on the machine and you can ignore the rest of this article. However, if you want to be able to make some additional configuration changes, read ahead.

Choosing a configuration

Before modifying any files, it is important to know that there are a variety of ways to configure apache. You could use a whole different IP address or you could just use a different port, on the same IP Address. This is the first item that you will need to determine. We will look at both approaches, because they are only slightly different.

The second thing that you will need to do is create a folder for the additional website. This is similar to how you would have done so with older versions of macOS Server. If you have an existing folder location, you can use that.

Once you have determined your approach and have created a folder, now we can start modifying the files. There is a standard apache configuration file, called httpd.conf. This is the primary configuration file for the apache service. The httpd.conf file is located at “/private/etc/apache2/httpd.conf”. You will need to open up the file with a text editor, either using terminal or a graphical text editor, like BBEdit.

Note:  macOS is Unix under the hood and can possibly require authentication when changing files. For this reason, it is best to use BBEdit for modifying files. BBEdit can handle this by providing an opportunity for entering in your password when saving the files.

Before modifying any file, you should make a backup copy of it. I always like to use the name of the file and its extension and put the date after file. Once you open this file you will need to make a couple of changes.

Making Changes

As mentioned, macOS Server takes into account the Profile Manager service. To accommodate this, there is a block of code that determines if macOS Server is using the default ports, which are 80 and 443. The following block is what is used to determine this.

   Listen 8080
  Listen 80

This block checks to see if is installed and configured. If it is installed and configured, the default port of 8080 is used for alternative. However, if is not installed and configured, then port 80 is used. Here is where you need to enter in your configuration. If you only need to listen on a different port, you can enter in “Listen 8081” where 8081 is the port you want to use. If you want to specify an alternative IP address use “”, where is the IP address you want to use. As the last example shows, you can specify a port if you need to, which means you can combine the two and use something like “”.

The next step is to test to make sure it is working as expected. To do this, you will need to create a file in the directory you chose. The file should have something like this code,

    <title>Test Page</title>
     <h2>This page is working</h2>

After you have saved this file, you want to test your apache configuration. This is done by performing the following steps:

  1. Open Terminal
  2. Type in, or copy and paste the following command, without the quotes: “sudo apachectl configtest”. This command will check the syntax of your apache configuration and make sure everything works.

If there are no issues with your apache configuration, you need to restart apache. This is complete by doing the following steps:

    In the same terminal window, type in, or copy and paste the following command: “sudo apachectl restart”, without the quotes. This command will either start up, or restart, the apache service.

The last step is to open up Safari and browse to your new site. You should a page with the text “This Page is working”.

These are just the basic steps to be able to host both a website and profile manager on the same Mac running macOS Mojave. You can do some additional configuration, by configuring Virtual Hosts and enabling Modules. Again, this is the same version of Apache that is installed on linux, so there is a plethora of tips, tricks, and how to to guides available on the web.

Transition Guide

There is an entire Support Guide for transitioning some of macOS Server’s services to the built-in version of Apache. This is available on the Apple Developer site. The document also includes information on transitioning the SSL, if configured, on the site. This should help some people get started with configuring apache on macOS, while still keeping Profile Manager running.