Day 6 : 13 June 2022 : Apple Developer Account - Certs, Apps, Profiles

My 100 Daze of Code

https://github.com/davidjwalling/100-days-of-code

Day 6 : 13 June 2022 : Apple Developer Account - Certs, Apps, Profiles

Our project scope includes porting Ava to iOS. We'll do that by building a simple SwiftUI app in Xcode that runs on iOS, install it on a 3rd-generation iPad running iOS 15.5 and debug and run the app. We'll integrate with our library (libava) by writing a thin Objective-C wrapper around the IDriver interface.

There are other frameworks for writing apps on iOS that integrate natively with C++ code. The Qt framework is one. But since SwiftUI support is included out-of-the-box with Xcode and does not require a paid license, we'll use that here.

Defining your Apple Developer Account

If you haven't yet created an account at developer.apple.com, now would be a good time to do so. After your account is created, you should reach this page when logging in.


As an individual account holder, your "Team Name" will be your name and you will have an assigned "Team ID". If you're part of a defined development team for your work, an administrator may invite you by email to join a team in a role, such as "Developer". At your place of work, your work email address may be a "member" of both a corporate team and have a personal Team ID.

Certificates, IDs and Profiles

What we're going to do next is create a certificate for use in signing your app, a application ID, which will be defined with specific attributes and entitlements, and a provisioning profile, which will be downloaded and referenced when building the app in Xcode. Once the app is built in Xcode on macOS, we install it on either an actual iOS device and debug it remotely, or we can run the app in a device simulator.

A Word About Networking on iOS

As we progress further along our 100-days-of-code project, we'll be adding considerably more code to our library, including networking code that runs over both TCP and UDP protocols. One of the mechanisms in UDP that we will use is the "broadcast." This feature is somewhat restricted on iOS versions 14 and higher. In order for an iOS app to send a broadcast packet, the application must have what is known as the "multicast networking" entitlement. This is defined in the app's entitlements file, a ".plist". But the app will not run correctly unless the account under which the app is signed has been granted the multicast networking entitlement. After setting up you Apple Developer Account, you can request the multicast networking entitlement at this page: https://developer.apple.com/contact/request/networking-multicast.

More about the multicast networking entitlement can be found here:

Creating a Certificate Signing Request

Before you can create a certificate, you first will use the "Keychain Access" app on your Mac to generate a "Certificate Signing Request" (CSR). The CSR is then uploaded to your developer account to create the the certificate. This is necessary so that Apple can sign your certificate, providing a chain of trust up to a trusted root certificate.

To create a certificate signing request, launch the "Keychain Access" app. From the app's menu, select "Keychain Access", then "Certificate Assistant", then "Request a Certificate from a Certificate Authority". This will open the "Certificate Assistant" dialog. Here, enter an email address and a descriptive name for the certificate. Select the "Saved to disk" radio button. Then click "Continue.


You'll be prompted to name the Certificate Signing Request file and select a location to store it on your Mac. Unless you are creating multiple requests, you can probably take the default values. Once you have updated the fields, click "Save".


Once saved, you have the option of selecting "Show in Finder ..." to locate the downloaded file. If you took the default "Desktop" location, there will be a new icon on your desktip. Click "Done" to close the dialog.


Creating a Certificate

Once your Certificate Signing Request (CSR) is created, you can return to your Apple Developer account online and create the certificate. Click on the Certificates, IDs & Profiles resource on the main menu in your Developer account. This will display lists of different types of identifiers that you have already created. The Certificates list is the default list shown.


Click on the blue "+" icon to open a dialog to create a new certificate. On the first page of the dialog, select the type of development you will be doing. Since our application is not limited to a single platform, I select "Apple Development". Note that this is for development use only. A different certificate type is required for distributing apps. After selecting the certificate type, click Continue.


On the next page, use the "Choose File" link to locate and select the Certificate Signing Request file created in the previous step. Then click Continue.

When the certificate is generated, you can download it using the "Download" button. This certificate will be added to the KeyChain and used to signed the app.


Creating an Application ID

On the "Certificates, Identifiers & Profiles" page on developer.apple.com, select "Identifiers" to list the current identifiers. Use the blue "+" button to start defining a new application. Here we'll create an application ID for the Ava project.



Select "App IDs" as the new identifier type and click Continue


Select "App" as the type and click "Continue."


Enter a description of the app and the Bundle ID, which should be "Explicit". On the "Additional Capabilities tab, if your account has had the "multicast networking" entitlement added, then check this box. This will enable the app to send broadcast and multicast frames on the network. Without this entitlement, your app can still listen on an address, accept connections, connect to a remote end-point and send TCP and UDP (unicast) traffic.


Review the application description and click "Register". When completed, the new Identifier shows on the Identifiers list.


Creating a Provisioning Profile

Lastly, we will create a provisioning profile for the app. On the "Certificates, Identifiers & Profiles" page, click on "Profiles" to list the existing provisioning profiles. Use the blue "+" button to start creating a new profile.


We'll use this provisioning profile for iOS apps, so select "iOS App Development" and click Continue.


Now, link the provisioning profile to the App ID we just created by locating the App ID in the drop-down and selecting it. I usually leave the "Offline support" option as No since I normally have an Internet connection available.


Select the Certificate(s) to include in the Provisioning Profile. You will have already downloaded this certificate or certificates. Note that it is possible to include more than one certificate. Be aware that certificates expire. So, depending on how long your development cycle is, you might need to update your certificates.


Select the devices on which you intend to install the app during development. In my case, I have one iPad I use for development testing. Your device may have been registered to your account using Xcode automatically. If not, you can use the "Devices" page within "Certificates, Identifiers & Profiles" to manually define your device.


Now give your provisioning profile a name. There is no real standard here. I use my project name and a date, since I might need to create additional profiles for the same project later. Then, click Generate.


Now download the Provisioning Profile and double-click on the downloaded file to install it.



Now we have downloaded both our Certificate and our Provisioning Profile, which identifies the Application and the Devices for our development project. Next time we'll create the workspace and application for iOS using Xcode, generate a sample SwiftUI app using the certificate and profile and run it on our iPad.











Comments

Post a Comment

Popular posts from this blog

Day 12 : 19 June 2022 : Adding Windows Service Logic

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #12 : Adding Windows Service Logic Today, we'll add some Win32 API logic in Ava to install, uninstall and run as a service on Windows. We'll add logic in Driver::Service that check if the program was started with the "service" argument as the first program argument. If so, the Service Control Manager will be invoked to start the program as a service. We'll also check for "install" and "uninstall" program arguments and handle these with logic that installs and uninstalls the program, respectively. In a later post, we'll do the equivalent on Linux and macOS and show how to enable Ava to run as a daemon configured in sysctl. Nowadays there are shortcut methods to install and run an executable as a service on Windows. But I prefer to illustrate the APIs that make this work. Some Code Refactoring Up to now we've been using a pointer-to-implementation (pimpl) method for exp...
Read more

Day 5 : 12 June 2022 : CMake on Windows

Image
 My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code Day 5 : 12 June 2022 : CMake on Windows So far, we've seen using CMake on Linux and MacOS. Also, we've looked at native compilation on Windows using Visual Studio (VS). Today, we'll look at using CMake on Windows. I decided to devote an entire day (hour) to this because there are several ways to invoke CMake on Windows, using different "Generators". A generator will write the inputs to the native build tools. But Wait, There's More ... Before heading to CMake, I wanted to first point out that VS' native tools can build just fine without using CMake, of course. To build using "msbuild," open an x64 Native Tools Command Prompt for Visual Studio - this is provided when VS is installed. Invoke msbuild and pass the solution name and the desired platform and configuration. msbuild ava.sln /p:Platform=x64 /p:Configuration=Debug Repeat for Debug and Release configurations for Win32 an...
Read more

Day 11: 18 June 2022 : Handling Program Arguments

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #11 : Handling Program Arguments Up to now we've been carrying around Ava's program argument count (argc) and value array (argv) into a Configure method. Now it's time to start doing something with those values. We'll define four program settings that can be set by passing program arguments: the logging level, path, prefix and suffix, and show examples of using them. Logging Parameter Storage The singleton theLog is instantiated inside the Ava library (libava). Default values for several logging parameters are set by the Log::Init method, which is called both by the Log class constructor and the destructor, by way of the Reset method, so that runtime values are not left in deallocated storage on operating systems that do not automatically clear memory upon deallocation. Logging Parameter Symbols We use namespaces and enums to define symbolic names for the logging parameters so that we have a single lo...
Read more