Tag Archives: Xcode

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.

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:

Share this:

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:

git branch -D yourbranch

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.

Share this:

Xcode 8 has this annoying habit to show missing files as warnings. This is happening when we delete a file that is referenced by a project using Finder rather than remove it using Xcode.

Technically it’s the git version control that complains about the missing files, not Xcode. However, since git says “yo, there’s a conflict between what should be and what is”, Xcode tells us this as a warning.

Be that as it may, how do we fix it before going insane? Lucky for us, it’s easy to fix. Here’s how.

Open a Terminal session and cd into your project directory. In here, simply type

git add .

As soon as you press Enter and return to Xcode, all those nasty warnings are gone. What we’ve done here is to say to git, “listen, this is the new state of the directory, please ignore what you think it should be”.

There should be no response from git, which is good news. All we see is no more missing file warnings in Xcode, and appropriate A and D icons in front of new and removed files as a result.

Share this:

To write cross-platform applications, it can be beneficial to have a single project with several target architectures. For example, we may want a macOS App inside a project that started out as iOS, and vice versa. Or we may want a different version of our app, perhaps a free one with less features, and an expensive one with more, based on the same code.

That’s where Xcode Targets come in. A Target is something that defines several build settings about an app so that when we press that popular button in Xcode, it knows what to do so we can see the built app in full colour. Trust me, there’s a lot going on under the hood – if you’ve ever tried to compile from the command line, you know how super helpful that button is. But I digress…

In this example I’ll show you how we can add a macOS Target to an iOS App’s Project. This will allow us to run and build either an iOS or a macOS version from common code.

Let’s begin. I’m using Xcode 8.3.3 for this by the way.

Adding the Target

In a standard Xcode Project for iOS, we already have a single target. Click on the blue project bar and select it from the list next to the File Inspector. It’s the one with the yellow icon: