#xcode 5

After not using Xcode seriously for a while, I found out Command Line Tools are no longer under the Download tab of the Preference of Xcode as before. I have to say this old way is very tight and convenient to an iOS and Ruby developer.

There are several questions and solutions around this issues in internet but the official description for it is here:

Command line shims are included with OS X Mavericks.

If Xcode is installed, the shims use the tools within Xcode. Otherwise, the tools delivered in the Command Line Developer Tools package are used.

The Command Line Developer Tools package can be installed on demand using xcode-select --install or by trying to use any command line developer tool in Terminal.

On OS X Mavericks, Command Line Developer Tools are updated using Software Update. On OS X Mountain Lion, continue to use the Downloads preferences in Xcode to update the Command Line Developer Tools.

Based on the above, it's unclear whether the Xcode 5 includes command line tools or not and I'm willing to see command line tools update using System Software Update in OS X Mavericks.

This is based on the book: iOS Programming: The Big Nerd Ranch Guide (3rd Edition) (Big Nerd Ranch Guides). I recommend this book because

it receives great recommendation from Amazon

i am using it myself and it really helps me to understand about objective c, cocoa framework, object-oriented and design patterns. it explains about the class objects from cocoa framework and how each classes are related with examples (e.g: inheritance, collection). it also explains about different design patterns such as delegation (callback in objective c), mvc, chain reaction and probably much more (ie: i am still reading it)

Here is my example of creating a simple location services on XCode5 with ios7

Figure 1: Screenshot of XCode which includes step 1 to 3 on creating a new Whereami project

On XCode, go to File > New > Project. Create a new Single View Application call "whereami" for iPhone. Important: Please note that creating a Single View Application in Xcode5 includes STORYBOARD. When you're using STORYBOARD, be sure to use initWithCoder. If you're NOT using STORYBOARD, use initWithNibName

Add CoreLocation.framework. Refer to Figure 1.

On XCode > Project Navigator, click on the top most "Whereami" (Step 1, Figure 1).

On the Editor area, Click go to whereami targets (Step 2, Figure 1)

Go to Build Phases

Expand Link Binary With Libraries (Step 3, Figure 1)

You should see 3 items: CoreGraphics.framework, UIKit.framework, Foundation.framework. Click on the + sign to add CoreLocation.framework

In WhereamiViewController.h do the following:

Import CoreLocation framework. Underneath import <UIKit/UIKit.h> add the following code:

#import <CoreLocation/CoreLocation.h>

Declare that WhereamiViewer conforms to the CLLocationManagerDelegate protocol by adding the the protocols within angled brackets in the interface declaration following the superclass like this:

@interface WhereamiViewController : UIViewController <CLLocationManagerDelegate>

Create CLLocationManager instance

CLLocationManager *locationManager;

The final code should look like this:

#import <UIKit/UIKit.h> #import <CoreLocation/CoreLocation.h> @interface WhereamiViewController : UIViewController <CLLocationManagerDelegate> { CLLocationManager *locationManager; } @end

In WhereamiViewController.m, add the following codes:

#import "WhereamiViewController.h" @implementation WhereamiViewController -(id)initWithCoder:(NSCoder *)aDecoder { self = [super initWithCoder:(NSCoder *)aDecoder]; if (self) { locationManager = [[CLLocationManager alloc] init]; [locationManager setDelegate:self]; [locationManager setDesiredAccuracy:kCLLocationAccuracyBest]; [locationManager startUpdatingLocation]; } return self; } -(void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations { NSLog(@"%@",[locations lastObject]); } -(void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError *)error { NSLog(@"Could not find location:%@", error); } -(void)dealloc { // Tell the location manager to stop sending us messages [locationManager setDelegate:nil]; } @end

Build and run the program. When you're running the simulator, you'll have to simulate its location by clicking the

icon, and select any location from the drop-down list.

If you're running for the first time, you will need to give permission for the application to use location services on the device. Wait for a few seconds while the location is found and you will see results in your console like this:

2014-01-25 08:32:48.905 Whereami[1355:70b] +/- 5.00m (speed -1.00 mps / course -1.00) @ 1/25/14, 8:32:48 AM Singapore Standard Time 2014-01-25 08:32:49.668 Whereami[1355:70b] +/- 5.00m (speed -1.00 mps / course -1.00) @ 1/25/14, 8:32:49 AM Singapore Standard Time 2014-01-25 08:32:50.669 Whereami[1355:70b] +/- 5.00m (speed -1.00 mps / course -1.00) @ 1/25/14, 8:32:50 AM Singapore Standard Time 2014-01-25 08:32:51.670 Whereami[1355:70b] +/- 5.00m (speed -1.00 mps / course -1.00) @ 1/25/14, 8:32:51 AM Singapore Standard Time 2014-01-25 08:32:52.671 Whereami[1355:70b] +/- 5.00m (speed -1.00 mps / course -1.00) @ 1/25/14, 8:32:52 AM Singapore Standard Time 2014-01-25 08:32:53.673 Whereami[1355:70b] +/- 5.00m (speed -1.00 mps / course -1.00) @ 1/25/14, 8:32:53 AM Singapore Standard Time Program ended with exit code: 0

That's it. Enjoy!!!!

References:

IOS Programming, The Big Nerd Ranch Guide edition 3

One of the coolest thing about working with technology is that technology is constantly changing and evolving.  A good case in point is to reach into your pocket and pull out the SmartPhone that you likely have there.  Think back to ten years ago or more and recall the cellphone you had back then – it probably made phone call, might have had the ability to take very basic photos and possibly had a text messaging feature.  If you were really lucky, it might have had a few decidedly basic apps, but nothing to call home about.

Fast forward to today.  That SmartPhone is a full featured computer.  Yeah, it can make phone calls, but what makes that Android Phone, iPhone or Windows Phone cool is that you can run a multitude of applications on it.  The demand for new and unique apps is strong no matter the device, yet there are some distinct differences in how these apps are created for each device, so we will take a look at the development environments for iOS and Android devices.

Before we go much further – we are not beholden to one platform or the other.  Indeed, Unbounded Solutions develops apps for Android and iOS, as well as for Windows Phone.  We’re also kicking the tires of Google Glass.  Our point being is that we’re not about to slam one platform just to sing the praises of the others.  We focus on developing mobile apps for businesses and organizations.  Period.

That actually gives us a good perspective to compare the development environment of iOS to Android. 

IOs and Xcode

Xcode is a polished IDE for developing iOS projects.  Ever since the launch of the first Mac way back in the 1980’s, Apple has been all about ease of use and decidedly intuitive interfaces.  That’s what set them apart from the IBM/Microsoft DOS competition back then, and so it is no surprise that mantra is found today, even when looking at developer tools. 

Apple has the benefit of a closed environment – they make the hardware, produce the operating systems and have a pretty heavy hand when it comes to allowing an app to be added to the iTunes store.  As an example, any iOS developer not adhering to the iOS 7 ‘flat design’ standards will be in a world of hurt come February 1st.  Apple has made it clear that if you don’t design towards iOS 7 specs, your app is likely to get rejected.

Android, Eclipse and an Open Source Environment

Unlike iOS, however, Android is open source, meaning that pretty much anyone can take the code and manipulate it to do things that it might not be able to do out of the box.  When this is done, the code is known to have been Forked.  Forked code typically isn’t supported as the standard code base, but it is exactly what allows companies like Amazon to produce their Kindle line of tablets.  They started with Android, and then made it unique to serve their purposes.  Very cool in its openness, but all those forks can gum up the works a bit for the developer.  There are a ton of variations in the Android ecosphere, as we discussed in our post about operating system fragmentation a few days back.

Just like the Android Operating System, the recommended development tool, Eclipse, is also open-source.  While we’re way past the days when open-source meant buggy and risky – Red Hat, JBoss and Spring Source have all proved it to be enterprise ready – there will always be some aspect that might cause some frustration.  After all, the nature of open source has a lot of individual contributors adding to the project.

When you look at Eclipse by itself, it looks fairly polished, but when you try to accomplish a task that might be done by simply dragging and dropping elements in Xcode, the process in Eclipse is not so simple.  Let’s use an example common to both iOS and Android development – creating a layout with table views.

In Xcode, the iOS developer can just drag and drop a TableViewController, make a cell prototype, set the outlets and then step up the respective delegate and data sources.  Then the developer can  edit the dimensions of this table view from the Xcode GUI Builder.  Pretty simple.

But in Eclipse, it is a bit more complicated.  There isn’t a GUI builder baked into Eclipse, so developers pretty much have to go to the manifest file of a list view and make changes to the dimensions there until the desired result is achieved.  Admittedly this is not a massive roadblock, but it is certainly a bump in the road to someone just beginning to learn how to do Android development.

We’re not trying to say that one environment is better than the other, but to instead state that they are definitely different.  It is important to consider these types of things if, like our company, your team needs to develop cross-platform solutions for your customers.  The timeline on the Android side likely will have different variables to factor in compared to your iOS development timelines.  Trust us when we tell you that your client will not know about these issues, and they probably won’t care.  It is up to you to set expectations from the beginning and understand how to target the delivery date with all of these cross platform development factors in mind.

As a example, by adding the code below into your viewDidLoad method a CALayer called backgroundImage will be displayed. This CALayer also takes on the contents UIImage named fixedBackgroundImage.

UIImage *backgroundImageSource = [UIImage imageNamed:@"fixedBackgroundImage"]; CALayer *backgroundImage = [CALayer layer]; backgroundImage.zPosition = 0; [backgroundImage setFrame:CGRectMake(0, 0, 1024, 768)]; backgroundImage.contents = (id) backgroundImageSource.CGImage; [self.view.layer addSublayer:backgroundImage];

find . -name "*.xib" -exec ibtool {} --upgrade --write {} \;

Apple made a gigantic step to make unit testing and continuous integration more enjoyable by making testing a first class citizen in Xcode 5. When you watch WWDC 2013 videos, you may be truly inspired by how easy it is to test and integrate using Mac OS X Xcode Service.

We still have to wait before Apple fixes a couple of bugs here and there, but not taking advantage of this great native support for testing and continuous integration would be rather hard to defend.

Ok, shortly, what does not work as it should and what can we do about it.

Signing Identities and Provisioning profiles

If your scheme supports creating an archive and you checked the Perform archive action in your bot settings (see the picture below) then you expect a ready to use, properly signed archive at the end of each successful integration.

Instead you may get two errors similar to these:

No matching provisioning profile found: Your build settings specify a provisioning profile with the UUID “9F2F3156-6380-4A91-AFA5-A68BD5781949”, however, no such provisioning profile was found.

CodeSign error: code signing is required for product type 'Application' in SDK 'iOS 7.0'

Apparently, the Xcode service on the Mac OS X server has big troubles retrieving the provisioning profiles from Member Center. Improving profile management was really Apple's big selling point for the Xcode service, so I am quite disappointed that this thing is not finished with the expected level of quality.

But first things first. This is what I see on my development machine when I look into the Apple ID account details in the Xcode Preferences:

My Mac OS X Server is running on another machine that I used earlier for development. I tried to configure both machines so that the machine on which runs Mac OS X Server mirrors as closely as possible my development machine. Unfortunately, Xcode had big troubles fetching all the Signing Identities and Provisioning Profiles from my member account. In particular, I could not make it fetching the iOS Distribution signing identity and my Ad Hoc provisioning profile. Creating an example project in Xcode and asking it to "Fix it" a couple of times also did not help. Only after I first exported Development Profile from my development machine and then imported it on the server machine, things started to look better. This operation also put all the required by Xcode keys into my keychain.

I hoped that if I now restart the server (by rebooting the computer) it will magically find all certificates and profiles and copy them intelligently to its secret locations. It did not.

In searching for an answer I found this: great blog post. I was put off at first with a post-build action script - if you still have to do this, then what's the point of using bots to create an archive - but still I managed to extracted some very useful information for which I am truly grateful.

Step 1 - fixing missing provisioning profiles

Copy your provisioning profile (it was an ad-hoc provisioning profile in my case) - the file with mobileprovision extension - to the following location:

/Library/Server/Xcode/Data/ProvisioningProfiles

I have downloaded my provisioning profile from the member center:

The location where you need to copy this file to is highly protected, so you will need to use sudo:

sudo cp your_profile.mobileprovision \ /Library/Server/Xcode/Data/ProvisioningProfiles/

This will fix the first error on our error list. If you run the integration again, you may still get the following errors:

No codesigning identities found: No codesigning identities (i.e. certificate and private key pairs) that match the provisioning profile specified in your build settings (“... Ad Hoc Provisioning Profile”) were found.

CodeSign error: code signing is required for product type 'Application' in SDK 'iOS 7.0'

The second one is our good friend now (well, it comes as a consequence of the first one), but we have to do something about new number 1.

Step 2 - fixing missing code signing identities

As described in the above mentioned article, you have to copy your iPhone Distribution certificate (see the picture below) to the server machine:

This is simple: just right (ctrl) click and choose Export... from the context menu.

> It may seem obvious, but make sure that your certificate contains the private key. There should be a small arrow on the left. When you click it you should see your private key unfolding (there will be a picture of a key on the left this time). If this is not the case for you, you have to find the complete certificate on some other machine.

Once you have it, you will need to import this certificate into your system chain on the server.

> If your Development Profile on the server machine is in sync with the Development Profile on your Development Machine (see the description earlier in this article), you already have this certificate but in the login chain. The Xcode service is not clever enough to find it there so you must copy it to the system chain.

This should get rid of our new error number 1 on the list. It also takes care for the error number 2, but as a gift it gives as a totally new error:

Command /usr/bin/codesign failed with exit code 1

It is not very verbal, but if you look into your log for the details you will find out this as part of the error description:

User interaction is not allowed.

What is this? Well, during code signing, Keychain Access is asking for confirmation and Xcode service does not find it convenient - of course.

Step 3 - fixing "User interaction is not allowed" codesign error

This issue is not directly described in the the article I mentioned at the beginning, but fortunately, there is a ready to use solution in the comment from one user:

> As per http://stackoverflow.com/a/14761060/1252368 the issue can be solved without scripting if you have access to the server’s UI – which you most certainly have when you use the Keychain Access application to install the certificate and identity.

> After you put the certificate and key into the system keychain, select the key and shows its properties via the context menu’s “Get Info” option. Then add /usr/bin/codesign to the list of allowed applications that can use the key without asking for permission first. You will have to enter your password one or two times to confirm, but once that is done, codesigning will work (just did it :) )

This should not be too hard:

Make your usr folder visible so that you can navigate to /usr/bin/codesign with Finder. You can use this command:

sudo chflags nohidden /usr

In Keychain Access, double click on the private key (the one with the picture of a key), select the Access Control tab and add /usr/bin/codesign to the list of "Allways allow access by these applications". Save the changes. You may be asked for your credentials more than once, but after successful authentication all should be fine.

> After adding codesign to the list you should see it on the list. However if you switch the tabs to Attributes and then back to Access Control, you will be surprised that codesign entry is no longer there. The same will happen if you close the property window and reopen it again. Don't worry. It is there, it just does not show. If you close Keychain Access completely and then start it again, the codesign entry will appear. It is all good.

Hide your usr folder from Finder if you want:

sudo chflags hidden /usr

This is it. Now Xcode service should be able to successfully create your archive.