Xcode 12 and iOS 14 Developer Bugs and Issues

I’ve had to put my game development adventures on hold for a bit since Apple released iOS 14 this week and I had to update my existing apps for the new OS version. I do this (more or less) every year so that the apps that I have on the App Store continue to support the latest functionality and takes advantage of any bug fixes in the new release.

This year has been rougher than most.

It feels as if Xcode 12 (and possibly iOS 14 too) is not quite ready and was rushed out the door. And the issues I’ve encountered are not deep-seated complex ones, but rather, very simple ones which seem to have been either overlooked, not tested for, or simply disregarded as “not worth bothering with”.

Here are some of the issues I ran into as a developer — I say “as a developer” because these aren’t all issues that might affect the end-user:

1. Storyboard view background color issues

I was updating one of my earliest projects when I ran into this issue. The app initially seemed to run fine and I was testing the various screens in the app when I hit a screen about two levels deep which was totally black. I could not see any of the text on that screen.

I initially thought that somehow that particular screen was switching to Dark mode since I was testing Dark mode at that point, but the device was not in Dark mode and if the screen had switched to Dark mode, then the text on that screen should have shown up.

I took a look at the storyboard and it looked fine:

Storyboard for my app showing the black screen viewed on iPhone SE (2nd generation)

But then, I switched the View as: device to iPhone 11 Pro and a weird thing happened:

The same storyboard viewed as iPhone 11 Pro

Some of the screens were now totally black and displaying the same issue I’d seen at run time. However, not all the screens which were black in the storyboard were displaying black at runtime.

Curioser and curioser …

I tried several different things, including making sure that the background of the views in question were set to the default color — normally, when I had color issues, that one worked most of the time. But this time, that didn’t work and none of the other things I tried had any effect on the black screens either. I was pretty close to tearing what hair I had left out at this point 😃

But then I decided to create a new project and check a view from that project against the views which were going black.

What I noticed was that on the new views, the background color was set to System Background Color instead of Default.

This was one of the affected views before the change:

View with original background color setting

And this is the same view after changing the background color:

View after changing background color setting

That seemed to fix the issue for the whole app — once I changed the background color for all the views.

Now, I have multiple questions:

  1. Shouldn’t a new view have the background color set to default?
  2. If there is a difference between existing storyboards and new ones, shouldn’t Xcode convert the old ones, or at least, warn the developer?
  3. Why the heck was the storyboard displaying fine when the view was set for one device but show issues when viewed as another?
  4. Why was this issue only showing up for some views at runtime? And that too on an iPhone SE (2nd generation) simulator which showed no issues at all on the storyboard?

I fear that I’ll not get any answers, but this whole experience made me think that the current version of Xcode 12 is not quite ready.

But it gets better … (or worse, depending on your perspective …)

2. Slider initial value

I had a screen with a slider where I ran into issues with setting the slider values in the storyboard only.

If you just plump a slider down on the storyboard and use the default values, the slider displayed fine when you ran the app:

Slider with default values

But if I modified the slider’s Value, Minimum, and Maximum settings, then the slider would always display with the thumb set to the Minimum, even though it should show what was set for Value:

Slider with modified values

The only way to get this to work correctly was to set the slider’s value in code before the screen was presented to the user.

A rather trivial issue, you might say. But the trouble is that the number of these trivial issues kept going up …

3. Cursor color does not match AccentColor

iOS apps (or even individual parts of an app) have a tint color setting which determines the color to be used by that particular screen, view, component, etc.

This value used to be set via the storyboard’s Global Tint setting. But now, you have a different (and in my opinion easier — in terms of discoverability) option to do the same — via the Asset Catalog’s AccentColor:

Two options for setting tint color

During the initial betas the AccentColor setting seemed to be a bit erratic at times. However, most of these issues appeared to go away by the time the Xcode 12 final release arrived.

There was one issue which still remains though — the cursor color for text views.

If you take a Text Field, when you tap into the Text Field, the cursor color displays what is specified by the AccentColor — note that my tint settings were as per the screenshot above:

Text Field cursor color

But if you tap into a Text View instead, the first time experience is different:

First time tapping into a Text View

If you tap out of the Text View (by tapping into the Text Field above it for instance) and tap back in, then the cursor suddenly decides to do a quick-change act:

Second time tapping into a Text View

Now I don’t know if this issue existed before AccentColors were introduced — maybe it did. But this is the first time, I noticed it. I add the caveat because it might not be fair to lump this issue in with AccentColors. But I noticed this only as I was trying to switch to using AccentColor for setting the global tint.

This one isn’t an Xcode (or iOS) issue per se, but is an issue with the supporting tools.

If you click on the Xcode menu, you’ll notice that it has an option for Developer Tools:

Download additional developer tools

That sub-menu allows you to download additional developer tools from the Apple site:

Where to download additional Xcode tools

One of the tools included in the Additional Tools for Xcode bundle is the Network Link Conditioner:

The Network Link Conditioner

In case you haven’t used this very useful tool, it allows you to simulate many kinds of network conditions on your mac so that you can test your app under different network conditions to see how well it behaves.

This is pretty useful if your app accesses data from the Internet and you want to see how it performs when the user has really bad mobile broadband.

The Network Link Conditioner (NLC) has worked flawlessly (at least for me) in previous iterations. But this time around, the results were spotty at best 😦

Sometimes you’d get the network conditions you set in the NLC. But most often as not, my network requests would just time out without anything happening at all. I would have to turn the NLC on and off again in order to get it to work at all!

5. Primary/secondary screens and master/detail segues

The last issue I’m going to highlight is not really a bug. But it speaks of the general lack of attention to detail that I’m seeing in Xcode this time around.

The UISplitViewController has had a bit of a facelift in iOS 14:

The split view controller in Apple documentation

Previously, there were two panes in a split view — master and detail. In iOS 14, Apple added the ability to have an additional pane.

Whether due to this change, or due to the Black Lives Matter movement and the surrounding discussions generated about everyday terminology connected to slavery that we all had taken for granted, or due to some other reason only known to Apple, the panes were now named Primary, Secondary, and Supplementary.

That’s all good. I have no issues with that.

But add a split view controller in your storyboard and Control-drag from the split view controller to another view and what do you get?

The old terminology still remains

The old terminology from before is still there in the pop-up menu. So what was the point of changing the naming in the documentation if it still remains in Xcode? Isn’t that confusing for the end-user?

And if you changed the terminology because you wanted to show that you were being more racially sensitive, doesn’t this send the message that the changes were just skin-deep?

I have filed feedback reports for some of these issues with Apple, but have yet to see any response from them.

So the overall impression I have is that they rushed with Xcode 12 (and maybe iOS 14 too). And I won’t even go into the whole releasing the GM, and then releasing the final version of Xcode 12 on the next day situation …

It feels as if they didn’t wait till Xcode 12 was done to release it — Apple just released things, at least this time around, because they had a schedule to keep. And that’s just not a good look …

Leave a Reply

Your email address will not be published. Required fields are marked *