Tag Archives: Xcode

Why is Xcode getting worse with each passing year?

I’ve been using Xcode since 2011, when Xcode 4 had just been released. Those were turbulent times, with Xcode 3 and Interface Builder having previously been two different applications, and Xcode 4.0 was the first “one app does all” approach to building iOS and macOS apps.

I remember Apple bringing out incremental upgrades every few weeks, with the jump from Xcode 4.1 to 4.2 being quite a leap in regards to features and/or the way you had to do things, coinciding with the release of iOS 5 and iCloud.

I’m telling you, turbulent times.

Xcode 4.3 was the first release to be distributed via the Mac App Store instead of a ZIP file from a hidden section in the Developer Portal. Upgrading wasn’t always easy slash possible, and I had more than one new version that just didn’t want to replace the existing one. Beta versions could still be installed side by side with the “release” version from the App Store, but the latter was from now on the only way to submit apps to the App Store.

Xcode 4 stayed with us for a while and let us program anything and everything up until iOS 6.1 and macOS Lion, until June 2013 when Xcode 5 was introduced. From when on, Apple chose to increment Xcode version numbers with each passing year until now, in late 2018, when we’ll soon be submitting our apps with Xcode 10 (which I haven’t even tried out yet).

I have to be brutally honest with you when I say that Xcode 5 was probably my most favourite release out of all the versions there have been. But I kept upgrading to Xcode 6, 7 and 8, being a little underwhelmed by how much more stuff Apple were trying to cram into their IDE every year. Poor Xcode!

With Xcode 6 came a new logo as well as Swift, which changed major versions what felt like every 12 seconds, and code from last week wouldn’t work anymore when used with a minor version update a week later. What a disaster! We also got Playgrounds and some more monitoring tools to play with, and – although clunky and frustrating to this day – Apple tried their best to make those evil provisioning profiles as automated and easy as possible.

When Xcode started turning into a buggy nightmare

There came the point at which the reviews on the App Store for our favourite IDE have been getting less and less kind. I remember the first bad reviews flying in when people had issues upgrading their version of Xcode. That was the most common complaint during the Xcode 6 and 7 era. Other than that, people seemed more or less happy with their development tools. Continue reading

How to use Version Control since Xcode 9

Xcode 9 has introduced a few changes in regards to Version Control is now handled. If you’re looking for the once so proud Source Control – Configure menu option, you’ll find that it’s no longer there. Dang! Where has it gone, and how are we supposed to manage our projects now?

Turns out there is a new tab in town, next to the Project Navigator (File manager icon) in the left hand pane of Xcode 9, called the Source Control Navigator. Click on it to find a plethora of options:

And would you look at that: for the first time in a decade, we can actually manage Tags as well as Branches here! And we get to see all those commits and comments we’ve been making for years, all without having to use additional version control tools! It’s like Christmas has arrived early!

Here’s a WWDC video on how we’re meant to use the new features from now on. It certainly didn’t answer all the questions I had, so for that, read what I’ve learnt through experimentation further down. Continue reading

How to create a macOS Project without Storyboards in Xcode 8

Since Xcode 7 we can now use Storyboards for the development of macOS apps. While that’s a welcome addition, not everything works as straightforward with macOS and Storyboards as it once did without them (Cocoa Bindings for example is still a huge mystery to me).

In Xcode 9 we have once again a choice when starting a new macOS Project, a simple tick box we had lost over the course of Xcode 8 and Xcode 7. For those of us who are still looking at Xcode 9 as “a little bit beta” and still like to work with Xcode 8, here’s a quick guide on how to create a new macOS project from scratch using good old fashioned XIB files with Xcode 8.3.3.

Let’s go through this process step by step, as we’ll have to do the whole setup manually. It’ll be very exciting, and a nice exercise, I promise!

Continue reading

What to do with “Linker Command failed with exit code 1” error in Xcode 8

One of those super ridiculous situations in which Xcode couldn’t be more unhelpful is if it tells you flat out: “Yeah erm… there’s an error here, but I’m not going to tell you where to start looking”. Other than the above error message, we see no log output or any further clue that may help us to investigate further.

Nice going, Xcode! You have such a dry sense of humour….

Lucky for us, there is a way to dig at least a little deeper by manually revealing what’s bugging Xcode: right-click the error message, and select reveal in log.

Now we can read the log file at our own leisure and see if we can make head or tail of it.

What is the NSPhotoLibrary Usage Description key?

Since iOS 10 and Xcode 8, Apple have added (yet another) security check for our apps. This time it’s about our apps accessing the user’s photo library.

While it was a courtesy to ask the user for permission to use the library before, since iOS 10 we have to add a special key to the app target’s Info.plist file and give a reason why we want to have access.

Here’s how to do it:

Navigate to your project’s target and select the Info tab at the top. In the long list below, hover over any row and click on the little plus icon that comes up. This should add a new row to the table (or in other words, add an entry to the Info.plist file).

Now type in NSPhotoLibraryUsageDescription. It should automatically turn into “Privacy – Photo Library Usage Description”.

On the right hand side of your new row we can add a string value, which will become the description in the dialogue shown in the screenshot above. It seems that we’re free to add whatever we want here, explaining briefly that your app needs access to the user’s photos.

That’s it!

On this note, there are two other keys that may come in handy for accessing the user’s camera and microphone respectively:

  • NSCameraUsageDescriptionKey
  • NSMicrophoneUsageDescriptionKey

Just as with photos, add these keys and a brief description if your app needs access to either the camera or the microphone. Something like “for image sharing” should do nicely. Here’s what that message looks like in context when iOS presents the dialogue to the user:

The dialogue is shown only once, not every time when the user wants to share an image. Should the user decline, or should s/he want to change this, we should explain to them that this can be done under iOS Settings – Privacy – Photos.

Demo Project

I’ve updated my Demo Project on GitHub with the relevant changes so that it now runs correctly under iOS 10:

For an extensive list of other useful NSkeys, check out this Stack Overflow thread:

How to delete a git branch with Xcode 8

Recently  I tried to merge some changes I had made on another branch back into my master branch, but Xcode wouldn’t let me. Spurious error messages prevented this from happening. I was happy to simply create a new master branch and overwrite it completely with the changes I had implemented on my former testing branch.

Turns out that Xcode is happy to create new git branches for our projects and screw them up several times in a row, but sadly, it is not capable of deleting branches.

So the simple answer to the title of this post is: it can’t be done!

However, a quick command in Terminal can do it for is. cd into your local project directory and issue the following:

where “yourbranch” is of course the name of your branch. Make sure you’re not currently on the branch you try to delete.

Doing this allowed me to simply create a new branch using Source Control – New Branch. When we do that, Xcode will automatically use the contents of our current branch as a starting point for the new branch and switch us onto it immediately.