The final build of iOS 14.0 will be released soon, and it’s about time to make sure our apps are running great on iOS 14. This year Apple introduced major changes in UISplitViewController, which are mostly dedicated to a new three-column layout and a sidebar. While the new sidebar UI looks great, in this post I will only focus on changes to existing functionality that we already use in our apps and show what can go wrong when your existing app is run on iOS 14. With that said let’s dive in.

New style property and why there is an unspecified style type

Probably the first thing that you’ll notice when looking at the UISplitViewController API exclusive to iOS 14 will be a new initializer that accepts UISplitViewController.Style as a single argument. While doubleColumn and tripleColumn styles are fairly self-explanatory, there is a third mysterious option called unspecified. After some testing, it became clear that unspecified style is a way to tell UIKit that you want iOS 13 behavior, so if you don’t want to deal right now with all the issues described next, you can enjoy the old behavior even when running on iOS 14, if you’ll use the unspecified style. The only issue with this scenario is that it is a bit tricky to set this specific style. Next, I’ll quickly summarize solutions that do and don’t work for such a task.

What does not work

1. Calling new initializer with unspecified style. The most obvious approach, however, it triggers runtime exception with a message

API misuse. -initWithStyle: may not be used with UISplitViewControllerStyleUnspecified.

2. Performing setStyle: selector. Leads to exception too with a message

SPI misuse. -setStyle: should be used by IB to set up UISplitViewController for column-style behavior using UISplitViewControllerStyleDoubleColumn or -TripleColumn (yep, there is a typo in that message).

What does work

1. If you instantiate your UISplitViewController in code, just call the default NSObject initializer: UISplitViewController().
2. Thankfully, there is also a solution for those who instantiate their UISplitViewController from the storyboard. In the 5th beta of Xcode 12, Apple allowed us to set the unspecified style directly from the Interface Builder.

Want to use the modern API instead? Great, stay tuned to see what breaks as soon as you’ll pick the doubleColumn style.

Clipped master view controller’s view

After choosing the doubleColumn style in Interface Builder and running my app I noticed that for some reason the whole master view controller was clipped.

The layout of the main menu view controller was created years ago when Safe Area layout guides were not present. Hence, the collection view was constrained to its superview, instead of Safe Area, which caused this weird clipping.

After enabling Safe Area layout guides in File inspector everything went back to normal.

As Geoff Hackworth explained in his Tweet the primary view controller is wider than its visible area to support the edge swipe when the primary view controller is hidden. Make sure you have “Show Device Bezel” enabled in Simulator to perform the edge swipe in it.

DisplayModeButtonItem is no longer accessible

After navigating a bit through the app I noticed the following message in the console

[Assert] displayModeButtonItem is internally managed and not exposed for DoubleColumn style. Returning an empty, disconnected UIBarButtonItem to fulfill the non-null contract.

This message showed up right after I tried to set leftBarButtonItem of a detail view controller, which was about to be presented:

Previously this solution allowed me to show a button at the detail view controller that could expand the view controller to the full width of an iPad.

However, on iOS 14 similar functionality is provided by default with a new button displayed on top of master and detail view controllers, so the legacy solution should be executed only on older iOS versions.

Tint color of expand & collapse button during the transition

If you look closely at the last gif, you’ll probably notice that the color of the button changes to standard iOS blue while the transition is going on while UINavigationBar.appearance().tintColor is used at other times. After inspecting the view hierarchy it turned out that there are 3 of such buttons.

Most likely one of them is shown only when the transition is in progress. After trying several approaches I figured out that the color of that button is defined by UISplitViewController’s view tint color.

Nonworking delegate callback

After fixing previous flaws I decided to see if everything is good when the app is run on an iPhone. Unfortunately, after launching the app I saw the placeholder view controller instead of the main menu and a message in the console saying

[UISplitViewController] Skipping delegate callback, splitViewController:collapseSecondaryViewController:ontoPrimaryViewController:. Unsupported for UISplitViewController style DoubleColumn

Thankfully, there is a new callback introduced in iOS 14, which we can use for the very same purpose:

Still, the warning about skipped delegate callback will be printed in your console (assuming that you’ve kept the previous callback to support the pre-iOS 14 systems).

Final thoughts

Overall I’m glad that this year’s migration to the latest iOS turned out to be not complicated at all. Hope you’ll update your apps without issues as well. If you enjoyed this post, please check out my app in the AppStore. That’s all, and thanks for reading!

iOS 14 UISplitViewController: 5 Issues That You May Run Into was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

iOS 13 brought quite a list of new features: SwiftUI, Combine, Dark Mode, RealityKit, iPad OS, etc. But several things were left almost unnoticed. Among them is a new appearance of some UIKit components. UISegmentedControl alongside with UISwitch, UIStepper, and UISlider got a new look.

Unfortunately, in the case of UISegmentedControl, those changes caused several issues which I describe next.

1. Tint color does not work anymore

The “tintColor” property introduced in iOS 7 allowed to change the appearance of UISegmentedControl.

Starting with iOS 13 “tintColor” does nothing. No matter what color you will assign, the appearance of UISegmentedControl won’t change. To make things even more unintuitive, Apple did not mark this property as deprecated. To give us at least some way to customize colors of UISegmentedControl besides the “backgroundColor” Apple introduced a new property called “selectedSegmentTintColor”. Using this property we can change the color of sliding control.

2. Default background images

While trying to pick a good background color for segmented controls in my app I noticed that the color I saw was a bit dull. After inspecting the view hierarchy, I found out that when custom background images are not set, UISegmentedControl uses some default images.

The fill color of those images can be replicated with black color with 6% opacity. What’s interesting is that we can’t get access to default background image as “backgroundImage(for: .normal, barMetrics: .default)” method returns nil in this case. What’s even worse is that if we set an empty background image (UIImage(), or any image technically) the white image with shadow beneath the sliding control disappears making resulting segmented control unusable.

Such behavior makes it impossible to use some pure background colors, e.g. white. Sure, we can assign it, but in the end, it will appear slightly gray due to blending with default background images.

3. Default rounded corners

Another problem arises when background images that cover all frame of segmented control are used. Starting with iOS 13 a corner radius is set no matter if custom background images are used or not which leads to clipped corners:

Fortunately, this issue can be fixed using the custom subclass of UISegmentedControl with overridden “layoutSubviews” method:

class SquareSegmentedControl: UISegmentedControl {
    override func layoutSubviews() {
        super.layoutSubviews()
        layer.cornerRadius = 0    
    }
}

Final thoughts

Overall I have mixed feelings about an update of UISegmentedControl in this iOS release. Sure the new look is interesting, but it may force us to adapt the design of other sections of our apps for them to look more natural alongside new UISegmentedControl, and there is no way to get complete iOS 12 appearance back to win some additional time necessary for app redesign.

There is a way to get partial iOS 12 style back, described at https://stackoverflow.com/a/56458794. But it will only work for solid color backgrounds, because in iOS 12 you could see the background view through the text of selected segment or uncolored portion of the unselected segment.

If you enjoyed this post, please check out my app in the AppStore. That’s all, thanks for reading!

This post has been updated to include the recent additions in Xcode 12 dedicated to In-App purchases testing.

One of the In-App purchases implementation steps that every developer eventually faces is a choice of a suitable purchase record persistence strategy which will make possible to give access to paid content after app relaunch.

The most obvious way of persisting the purchase is to store some value in UserDefaults that will indicate whether or not some content has been unlocked. Such approach is shown in two tutorials at raywenderlich.com written by Owen Brown and Pietro Rea, where UserDefaults are used to store a boolean flag to indicate non-consumable products purchase status as well as Date instance to persist the subscription expiration date. Such a solution is often criticized due to lack of data integrity protection, as content present in UserDefaults is stored as an ordinary binary plist in the Preferences folder of app's bundle and thus can be edited by the user using software like iMazing, iFunBox or iExplorer as shown by Andrés Ibañez in his 2014 post.

While this is true, I would like to mention that since iOS 8.3 Apple introduced serious permission restrictions in file system access, which eliminated access to application’s internal files from outside on non-jailbroken devices. Speaking about Jailbreak, it is worth reminding that its popularity has been decreasing over last years to the point that its pioneers say that jailbreaking is dead. From personal observations, I can say that it takes more and more effort to release an untethered jailbreak for the newest iOS version. Starting with iOS 10 it takes at least 6 months for hackers to release a jailbreak, which can be used by an average iOS user. It is why I think that the chances are pretty low that any significant portion of the app’s users would tamper with app’s files.

Still, it doesn’t take much effort to use a Keychain instead of UserDefaults as shown by Axel Kee in his post. The principle is the same — store a string like “purchased” for identifiers of purchased products. It is worth mentioning that in iOS 10.3 betas, Apple started to remove all app-related records in Keychain after app uninstallation. However, as it turned out, many people relied on the previous behavior of Keychain even though it wasn’t documented, and Apple had to revert this change in iOS 11+. The bottom line is that if you want to persist In-App purchases between app installations, you can use the Keychain, but Apple may change its behavior once again in the future.

There is, however, an alternative approach to check if a user has purchased something without relying on UserDefaults or Keychain by using a receipt, which is automatically updated by the OS on every purchase. Even though the idea of receipt usage for this purpose is clearly documented in Apple’s In-App Purchase Programming Guide, it seems like this approach lacks attention in 3rd party tutorials. One reason for that might be that this persistence strategy is applicable only for non-consumable products and auto-renewable subscriptions. If you are implementing either consumable or non-renewing subscriptions, then you are left with Keychain, iCloud, or your own backend. The second obstacle of app receipt usage is its complex structure that requires a good amount of tricks to read the necessary information. The tutorial by Bill Morefield does a good job in showcasing what it takes to read an app receipt in Swift without 3rd party dependencies. Thankfully, folks from Cocoanetics created a Kvitto library, which makes work with an app receipt a breathe. Alternatively, you can also use a TPInAppReceipt library by Pavel Tikhonenko for the same purpose.

Recently I successfully implemented both non-consumable purchase and auto-renewable subscription in my app called Electronics Engineer Helper using app receipt as a persistent record of the purchase. The method of InAppPurchaseManager that reads the receipt looks like this:

The method simply parses receipt to find relevant entries by comparing the product identifier and uses tuples inside of the switch statement along with ternary operations to return appropriate purchases status.

Another method worth checking out is a paymentQueue(_:updatedTransactions:) of SKProductsRequestDelegate:

In this method I simply forward events to BehaviorRelay (a class from RxSwift library) and read purchase status from app receipt when all transactions have been handled.

In Xcode 12, Apple introduced a new In-App purchases environment called Xcode and StoreKit configuration files. By adding such a configuration (File > New > File … > StoreKit Configuration File) you can now test In-App purchases both in a simulator and physical device without resorting to workarounds like specifying purchases status via the environment variable.

What’s also great with StoreKit testing is that not only your code is called in exactly the same way as in the production environment, but you also see a production-like purchasing dialogs.

With a new Transactions Manager, you can easily remove purchases from the receipt and simulate edge cases like interrupted or deferred purchases.

You can check out the full code of my InAppPurchaseManager in the gist. By leveraging RxSwift, Kvitto, and app receipt an implementation of In-App purchases didn't cause much trouble.

If you enjoyed this post, please check out my app in the AppStore, and thank’s for reading.

In this post, I would like to focus specifically on the evaluation of potential slowdown during iOS apps compilation.

Spectre and Meltdown fixes aftermath

To find out whether there is any significant difference between build time on macOS versions with and without fixed vulnerabilities, I used 3 apps written in Swift: Firefox (master, 4cd9bcd), Kickstarter (master, 445373b) as well as my own free app Electronics Engineer Helper. Each project was compiled 16 times on each macOS version using a simple bash script

#! /bin/bash

PROJECT_NAME=$1
SCHEME_NAME=$2
CONFIGURATION=$3

for ((n=0;n<16;n++));
do
    rm -rf ~/Library/Developer/Xcode/DerivedData/*
    /usr/bin/time -p xcodebuild -project $PROJECT_NAME -scheme $SCHEME_NAME -configuration $CONFIGURATION -sdk iphonesimulator build > /dev/null
    sleep 10
done

…which was used with following input arguments

./profile.sh Kickstarter.xcodeproj Kickstarter-iOS Release
./profile.sh Client.xcodeproj Fennec Firefox
./profile.sh “Electronics Engineer Helper.xcodeproj” “Electronics Engineer Helper” Release

It’s important to manually clean DerivedData folder before each run, as simply passing clean command to xcodebuild will not remove the ModuleCache, and so the duration of a first and all following builds will be slightly different.

All apps were compiled using Xcode 9.2 (9C40b) on a Hackintosh featuring Core i7 6700K CPU (4 cores, 4 GHz), 32 GB of RAM (DDR4, 2400 MHz) and Kingston KC1000 SSD (NVMe, 240 GB, PCIe 3, 4 Lanes). DerivedData was located on a RAM disk created using the iRamDisk app.

With all data collected, a mean build time as well as margin of error at 95% confidence level was calculated. The calculation of margin of error will help us to better understand whether any difference between two OS releases is just a random fluctuation or not.

With that said, let’s see the results.

                                        Build time, seconds
          Application            ---------------------------------
                                     10.13.1           10.13.3      
 -----------------------------   ---------------   --------------- 
  Kickstarter                    302.776 ± 0.299   308.541 ± 1.344  
  Firefox                        146.935 ± 1.297   151.014 ± 0.949  
  Electronics Engineer Helper    165.211 ± 0.525   171.021 ± 0.537

Conclusion

The slowdown due to Spectre and Meltdown fixes is definitely present, but the good news is that it is barely noticeable. For mentioned projects, the build time increased on average from 1.9% to 3.5%, which is similar to the results of other benchmarks posted on the web.