Posts

As an iOS developer you need to periodically update your Xcode, on your own machine and on your CI/CD server if you automate your development workflow. There are multiple ways to do this so do not waste your time and use the fastest way possible.

Forget Mac App Store, use Apple Developer Portal

Installing Xcode from the Mac App Store might seem like a convenient way to do so but it is too slow and inflexible. You cannot use the Mac App Store to install multiple version of Xcode at the same time if you need them, like when testing with a Xcode beta for an upcoming iOS release. Download from the Mac App Store is incredibly slow and sometimes not even available for days after release (like 11.2.1).

The place to go is the Apple Developer Portal where you can find all the Xcode versions, including the betas.

Faster download with aria2

Downloading Xcode from the Apple Developer Portal is faster than using the Mac App Store, but it can be made even better. You just need to use the right tools.

Install aria2 from Homebrew and uses this Ruby script from Ian Dundas:

#!/usr/bin/env ruby

print "What is the URL of your Apple Downloads resource?\nURL:"
url = gets.strip

print "What is the ADCDownloadAuth cookie token:\nADCDownloadAuth: "
token = gets.strip

command = "aria2c --header \"Host: adcdownload.apple.com\" --header \"Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\" --header \"Upgrade-Insecure-Requests: 1\" --header \"Cookie: ADCDownloadAuth=#{token}\" --header \"User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_1 like Mac OS X) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0 Mobile/14B72 Safari/602.1\" --header \"Accept-Language: en-us\" -x 16 -s 16 #{url} -d ~/Downloads"

exec(command)

This script downloads the given Xcode by URL from the Apple Developer Portal, but uses up to 16 separate connections to do so. You will see a significant download speed improvement.

Make sure you use the “More” site at https://developer.apple.com/download/more/ even for downloading the latest version of Xcode.

When copying the ADCDownloadAuth cookie make sure you copy the correct value, Safari adds all kinds stuff around it when you just use “copy value”.

Faster install with xip and deleting previous Xcode first

When you install the Xcode xip file you need to extract it. You can double click it in Finder and wait or you can use

xip -x Xcode11.xip

Using xip from the command line is much faster because it does not verify the file signature like double clicking in Finder. Of course this is a potential security risk, so it is up to you to decide if it is worth it.

Another trick is not to drag the extracted Xcode.app to /Applications immediately but delete the existing /Applications/Xcode.app first. I guess this is related to Finder first getting the list of those thousands of files in the Xcode.app before the update.

When developing an iOS application you might get into a situation when you need to change the UIApplication base class. It is often a requirement when using various MDM SDKs, like the Mobile Iron AppConnect SDK. There are two ways to do that in a Swift application, both with some advantages and disadvantages.

Declarative method with Info.plist

The first method to change the UIApplication base class is using Info.plist. It is quite simple, you just need to add a new key NSPrincipalClass with a string value representing the name of the desired class, like AppConnectUIApplication when using the Mobile Iron AppConnect SDK.

<key>NSPrincipalClass</key>
<string>AppConnectUIApplication</string>

No actual code changes are required.

Code method with main.swift

The second method is a bit more complicated but more flexible at the same time. First you need to remove @UIApplicationMain from your AppDelegate class definition. Then you add a main.swift to the root of your project that looks like this

import AppConnect
import UIKit

UIApplicationMain(
    CommandLine.argc,
    CommandLine.unsafeArgv, 
    ACUIApplicationClassName,
    NSStringFromClass(AppDelegate.self)
)

The third parameter in the UIApplicationMain call is the name of the desired class, ACUIApplicationClassName in this example.

The iOS messaging application I work on features a context menu in the chat. You long-press any message in the chat and the context menu appears. This menu was originally implemented using the standard UIMenuController.

The UIMenuController is an old-style iOS API that is hard to use and does not work very well. In some situations tapping its items just did not call the assigned selectors and the menu did not work.

As part of the ongoing redesign of the application I decided to implement a new custom context menu that would look as the designer imagined and more importantly work reliably. I did not want to use any 3rd party library to keep it as simple and possible.

Using just UIKit I came up with a context menu with a dim effect and a highlight on the selected item

Here is how I approached building it.

If you use the standard iOS UIAlertController to present the user with a list of actions, there is not much you can do about styling each of the UIAlertActions shown.

The text of the shown UIAlertAction uses the UIView's tint color, so you can use the UIAppearence API to change it to any color you want, but the same color for all the UIAlertActions. If you set the style to destructive instead of default, the text is shown as red, not affected by the tint color.

UIAlertController with one default and one destructive action might then look like this with dark blue set as the global tint color using UIAppearence:

The red color for the destructive option does not look that great, especially if your app uses a different shade of red everywhere else.

If you dive deep into Apple documentation you will find a KVC called titleTextColor. This KVC allows you to set exactly what you need, the color for the UIAlertAction text.

When I started with my hackintosh I did not have Wi-Fi or Bluetooth support in it. I used Ethernet to connect to my home network and it worked fine, I had no need for Wi-Fi.

Later I wanted to use more “Apple-specific” features, so I started looking for how to make them work with my hackintosh.

Bluetooth

Adding Bluetooth support to a hackintosh is quite easy, you just need to buy any of these USB adapters:

• IOGear Bluetooth 4.0 Adapter
• GMYLE Bluetooth 4.0 Adapter

All of them are natively supported in macOS, no extra drivers are needed.

GMYLE Bluetooth 4.0 Adapter

I bought the GMYLE Bluetooth 4.0 Adapter, found it on German Amazon.

Thanks to adding Bluetooth support I got:

• Ability to use Bluetooth keyboards, speakers, headphones
• SMS messages showing on macOS
• incoming phone calls showing on macOS

The SMS relying feature was really nice, especially when needing to copy security codes sent by SMS by services that do not support 2FA via TOTP.

Justa s a side note, iMessage worked right from the start, Bluetooth is not needed for it.

Wi-Fi

Wi-Fi required for some Apple-specific features

The one thing that I was missing was AirDrop. I started taking screenshots regularly on my iPhone during development and testing and there was no easy way to move them to the hackintosh without AirDrop.

To make AirDrop and additional features like Handoff work you need not only Bluetooth but also an internal Wi-Fi card.