Not only is Xcode an excellent IDE for iOS and macOS apps in both Swift and Objective-C; it does just as fine a job for regular C and C++ code. This includes all the features we know and love, such as code completion, version control, and all the rest of it.
Let’s see how to use Xcode 8.3 for C and C++ development.
In this screencast I’ll show you how to make an iPhone storyboard display as an iPad storyboard in Xcode 5.1’s Interface Builder. Under the hood a UIStoryboard is just an XML file, and with a small tweak we can make Xcode display it like an iPad or an iPhone. This is a good strategy if you’d like to use your iPhone storyboard as a starting point for an iPad version.
In this screencast I will show you how to bind a Table View to an Array Controller in Cocoa, using Xcode 5.1 and OS X Mavericks. We’re using Core Data to save our entries and – check it out – we’re not writing a single line of code!
Cocoa Bindings is one of the most exciting features in OS X development for me, and I hope that one day it’ll find its way into iOS too.
The project is also available on GitHub: https://github.com/versluis/Bindings-Demo
I’ve written more about how to do this here: http://pinkstone.co.uk/binding-an-nstableview-to-core-data-without-code/
In this screencast I will show you how to tear down your Core Data Stack. Documentation on this topic is a little sketchy to say the least.
We’ll create a new Master/Detail app and implement a button that will remove the store file and reset the entire stack – without nasty error messages or app crashes. The app will work on iOS 7.1 and iOS 6. I’m using Xcode 5.1 in this demo. The principles of course apply just as much to Mac Development.
You can read more in my companion article here: http://pinkstone.co.uk/how-to-tear-down-your-core-data-stack/
There’s also a GitHub project that shows the full app (find the link in the same article).
In this video I will show you how to use the Git Branch feature in Xcode 5.1.
Branches are helpful if you’re developing your app. You can isolate a “working” version, create a new branch and fiddle with new features that may destabilise your project. You can then commit your changes – working or not – to a separate branch, and when all is stable again you can merge them back into the master project.
I use this feature for plugin and theme development, in fact for any “group of files” that will change over time. If you’re not using Xcode, take a look at the GitHub Apps which are available for Mac and Windows. They make version control a breeze on your local system, integrate flawlessly with GitHub.com as well as SSH remotes on your own server.
In this video I will show you how to make use of Tags in Git. This is not supported in Xcode or GitHub for Mac at the time of this recording (April 2014). I will also show you how to utilise the Tag/Release feature on GitHub.com.
Tags are a useful feature if you want to mark versions of your software before you add new features. With Tags you can always go back to the code of a release.
We’re using Xcode 5.1 and the Terminal utility for this.
I use tags and branches for plugin and theme development too, in fact for any “group of files” that will change over time. If you’re not using Xcode, take a look at the GitHub Apps which are available for Mac and Windows. They make version control a breeze on your local system, integrate flawlessly with GitHub.com as well as SSH remotes on your own server.
I understand there can be many reasons for this error message. Xcode needs a distribution profile with the same Bundle Identifier as the app. Even though this seemed to have worked in the past, Xcode 4.6.3 has gotten more pernickety as of late.
Select the Plus Button to add a new profile. Select App Store under Distribution and hit continue.
Next you’ll have to select the App ID for your project. Once selected, hit continue and give your new Distribution Profile a name (I’d use the name of your app). You’ll pre prompted to download the profile on the next screen.
Note that this isn’t necessary as Xcode can import those automatically – let’s do that next.
Back in Xcode 4.6.3
Open the Organiser (under Window) and select Devices. Under Library, find Provisioning Profiles and see a (probably very long) list of currently installed profiles. At the bottom right of that screen there’s a Refresh button – click that and Xcode will talk to the Provisioning Portal, importing and updating all profiles in this list. Your new one should have been added to the list after a few seconds.
Now quit Xcode and restart it
This is crucial for the automatic profile selector to refresh – otherwise your new profile won’t show up for selection. Don’t ask! I’m sure it’ll all be “so much better in Xcode 5″ (yeah right). Anyway…
Select your project’s Big Blue Bar (I’m not sure what it’s called, the one above the target) and select Build Settings. In here, find the Code Signing section – you can search for it at the top right or just scroll down. The block you’re looking for looks like this:
Select your Developer Profile for the first two options, and your newly created Distribution Profile (with matching Bundle ID) for the latter two, just like in the screenshot.
Head over to Product – Build and with a bit of luck the error should have gone.
I’ve often wondered how to use those efficiently, and I’ve just found out how to do it. As always, they’re not difficult to implement – but not documented in a way that simple folk like me can understand it. Be that as it may…
Preprocessor Macros can be useful if you’d like to compile two different versions of the same Xcode Project, such as a Lite and a Pro version, or a separate iPhone and an iPad version. Rather than create separate Xcode Projects for each version, you have one project with two targets. Each target can build a different version from your code, making maintenance much simpler than having to change the same code in two projects.
How do they work?
Preprocessor Macros are directives executed by the compiler, so they’re not part of Objective C. We’ve used them many times before with the #import statement. But to stay with our Lite and Pro example: you can use a Preprocessor if/then statement to check which version is being compiled. For this, let’s define a Macro for the Pro version. Here’s how in Xcode 4.6:
Let’s define one
Click on your Pro Target, head over to Build Settings and search for Preprocessor Macros. You’ll see something similar to the above screenshot. You can set Macros for each build configuration. By default we have two: Debug and Release. Notice that the Debug configuration already has a Macro defined – it’s called DEBUG=1. Therefore out of the box you can already check in your code if it has been compiled with the Debug or Release configuration.
To define your own Macro, click the little plus sign next Debug (and Release) and add something specific. I’m using IS_PRO=1, but you can choose anything you like really. I don’t know if you can set values other than boolean. Make sure you set your Macro in BOTH configurations, otherwise you’ll find different results when you submit your app.
How to check them in Code
Now that your Macro is defined, you can check if it’s present in your code like so:
NSLog(@"It's the PRO version");
NSLog(@"Mustbe the LITEversion");
And that’s all there’s to it! This makes most sense with Targets which we’ll discuss next.