Validating Your Version of Xcode

Ghost in XCode

Apple recently removed many apps from the appstore which were built with fake version of XCode. Most of these apps were submitted for the Chinese app store.

The reason being, in China the Apple servers are very slow. So when the developers download XCode which is more than 3 GB directly from the AppStore, it takes hours for them to finish. As a result they download the XCode from some other third party mirror links. But this copy of the XCode is a malicious one is already infected by the hackers. As a result when we build our apps with this version of XCode, malicious code is injected with our app.

So we must be very careful with where do we get our XCode from.

Apple already have a way to find the malicious apps from the OSX 8 called GateKeeper which tells the user whenever we try run a malicious (not code-signed) application in our Mac. But if you disabled the GateKeeper in your Mac you won't get the warning.

Apple sent out mails to all the developers to check if they are using the right version of XCode. To find out if you are using the un-infected version of XCode, run this command in the terminal

spctl --assess --verbose /Applications/Xcode.app

More info on this here:

https://developer.apple.com/news/?id=09222015a

User defined run time attributes

User defined run time attributes are one of the hidden(likely) gems of the XCode which helps you to customise/configure your UI object in the interface builder itself, without having to write code.

The "User defined run time attributes" uses the Obejctive-C's already existed concept called Key Value Coding. With the Xcode 6, this is a game changer, see here IBInspectable and IBDesignable

Key value coding is a mechanism which helps us to access the properties of an object indirectly by name (or key, which is a string) rather than directly using the accessor method.

That means, say for example you have the property text for the UILabel, you can use the user defined runtime attributes for changing its value.

Wait, who would do that? The UILabel control already have the IB properties for giving the text.
But, think of some other properties that the IB doesn't have. You can do that in the u.d.r.a (ah.,, user defined run time attributes, I am tired of typing this).

For example, here I have a custom class called CustomLabel which is a subclass of UILabel which have a property called fontName. When I give string here, my CustomLabel will use this string and updates it font. I can assign the value to this fontName in the Xib itself like this.






The fun part is you can give not only key but also the key paths. (For those who doesn't know the difference between the key and the keypath, text is a key for the UILabel whereas layer.cornerRadius is a keypath for its corner radius)

For example, if you want to change the corner radios of a UIView, you can add a u.d.r.a  with the keypath layer.cornerRadius.

Don't try to give the layer.borderColor in this way, because borderColor needs a CGColor object but you can only give UIColor with the u.d.r.a. If you want to achieve this, you can add a category for the CALayer with a UIColor property and you can write your own logic to change its borderColor.

Note:
  If you give a u.d.r.a to a UI object, that doesn't have a property with that name, you will get a warning from the debugger like this. In the previous Xcode, it will raise a invalid argument exception and crash.

Here is a list of attribute types that you can use in the u.d.r.a.

For the sake of clarity, I am adding the screenshot of my CustomLabel class here.

Here is the link for the Apple Docs in this topic.

How to change the UITextField's height in the Storyboard/Interface Builder?

When you design your interface for iOS, you can’t change the height of the UITextField directly in xib, when the textfield’s type is UITextBorderStyleRoundedRect. If you need a little taller text field, especially for iPad, either you have to do that in code or you have to change the text field type to some other. But this little trick will help you to do that in xib itself. 

If you are using the constraints, you may specify the height constraint for the textfield.

1. Give some identifier to your textfield, so that you can find your textfield easily in the next step.

2. Right click the storyboard/xib file, select Open As -> Source Code. The storyboard/xib is basically an XML, so its attributes can be edited directly. 

3. Search your textfield, and change its height attributes. I have given 40 for my textfield here.

<rect key="frame" x="195" y="152" width="211" height="40"/>

4. Now if you open your xib as Interface Builder - Storyboard file, by following the step 2, you will find your textfield’s height bigger.

Here is the video if want to take a look.

So easy as it looks like. You can also edit any attributes of any controls like this. But, make sure you don’t break the file format.

Besides, I am wondering why apple’s HIG don’t allow to change the text field height.

IBInspectable and IBDesignable

One of the cool feature that was introduced in the Xcode 6 is enabling interface builder attributes for your custom view. i.e., the attributes that appears in the right when you click a control in the interface builder. Your custom control can have its properties right in the interface builder itself.

The closest thing you would do previously is, add your custom properties in the User defined run time attributes.

Previously, when you use a custom control, you have to do all the things by code. But now with this new feature, you can design your custom view in the interface builder itself. You can see how your custom view will appear while designing. There will be a lot of open source libraries in the future using this.

Apple have introduced two new attributes to make this happen IB_DESIGNABLE and IBInspectable. You have to prefix IB_DESIGNABLE before your custom view and add IBInspectable as the attributes to its property. So, a sample class will look like this.

The following types can be used for IBInspectable.

• Boolean (BOOL)
• Number (NSInteger)
• String (NSString)
• Localized String
• Point (CGPoint)
• Size (CGSize)
• Rect (CGRect)
• Range (NSRange)
• Color (UIColor)
• Image (UIImage)

The properties that have the IBInspectable attribute can be configured in the attributes inspector of the interface builder. And they will appear in the User defined run time attributesalso. They both can be used interchangeably.

You can write your code in the .m file with the IBInspectable properties setters or the drawrect method.

You can also debug your custom view without running. Simply open a assistant editor and put a breakpoint in your code and Choose Editor > Debug Selected Views.

IBInspectable can be used in your custom UIView/UIControl subclasses, categories, extensions. Don’t do expensive coding with the IBInspectable properties. The interface builder will try to compile the code no longer than 200ms. If it can’t compile within this period, the Xcode gives error.

In the first screenshot, I have added a custom text field which is of course a subclass of the UITextfiled.I can change the border color of the text field from the interface builder itself.

The apple docs is here and the sample source code is in the github.

Grap the code and play around yourself and make some useful controls with this. 

Key Value Coding and Key Value Observing

Key Value Coding:
Key value coding is a mechanism which helps us to access the properties of an object indirectly by name (or key, which is a string) rather than directly using the accessor method. The key value coding cannot be confused with the NSDictionary’s keys.

For e.g. the UITextField has a property called text which gives the current text displayed in it.
You normally access it by calling the following accessor method of the UITextField.

[myTextField setText:@"Hello"];
NSLog(@"%@", myTextField.text);

The above statements can be re-written by using the Key-Value coding as follows.

[myTextField setValue:@"Hello" forKey:@"text"];
NSLog(@"%@", [myTextField valueForKey:@"text"]);

The KCV can also be nested.
For e.g

[self.view setBackgroundColor:[UIColor blackColor]];

can be replaced with

[self setValue:[UIColor redColor] forKeyPath:@"view.backgroundColor"];

Key Value Observing:
Key-value observing is a mechanism that allows objects to be notified of changes to specified properties of other objects
For e.g. The UITextfield has delegate whenever it’s text changes, but it doesn’t have the delegates to inform about it’s colour changes. You can observe those with the “Key Value Observing”.
When you add an object as an observer for a textfield for it’s text property, whenever the text value of the textfield changes, the observer method of the object is called with the arguments.

    [myTextField addObserver:self forKeyPath:@"text" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:NULL];

-(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context{
    NSLog(@"%@ \t %@ \t %@", keyPath, object, change);
}

The KVC can be used for our custom objects by default. You don’t have to do anything separately to support the KVC i.e

[myObject setValue:@"Hello" forKey:@“foo”];

will work if the myObject have a property called foo.
But to support KVO for your custom objects you have to make use of the following methods inside object's class.

[self willChangeValueForKey: @"foo"];
[self didChangeValueForKey: @"foo"];

KVC and NSArray:

NSArray has some amusing functions with KVC's. You can see them in the following screenshot.

ScreenShot:

KVC in Xib:

     You can use the KVC directly in the Xib also. See the following screenshot. I have changed the corner radious of a view directly in the Xib itself. No coding needed. You can do the same for your own custom objects too.

Notes:

    If the object doesn't have the key you passed, the setValue:forKey: will raise an exception. 

    The keys are case sensitive.

    The KVC is little slower.

References:




StackOverFlow

Key-Value Observing Programming Guide

Key-Value Coding Programming Guide

#warning pragma in XCode

#pragma's are one of the interesting part of the XCode, which helps to organise your code.
When your .m file contains thousands of line and hundreds of methods, the file becomes clumsy.

You can avoid this by structuring the code by grouping methods with pragma marks. When you give pragma directive over a method, all the methods under this pragma are grouped together in the document items. You can see that in the following screenshot.

But the fun part doesn't end here.

Have you ever hard-coded something in your code for testing something, and you forget that completely. Well, that happens a lot. What if something reminds you to fix this when you finish your work?

XCode have a pragma directive particularly for this. It is the #warning pragma. Whenever you give a warning pragma anywhere in your code, the XCode compiler gives a real warning (yellow triangle that appears near the line number). You can see the compiler warning in the line navigator, Issue navigator like the other XCode warnings.

But this doesn't stop your code from executing, you can use the #error pragma if you want to stop the code from execution.

You can also make use of some comments that start with the following keywords.
// FIXME:, // ???,  // !!!, // MARK

The comment you enter after these will appear in the document items (Option + 6).

Apple shuts down the Testflightapp.com service after February 26 2015

Apple purchased the build distribution service Testflight from its previous owner Burstly almost year ago. After this acquisition, apple dropped support for android from Testflight, there is no wonder in that.

Also, apple started to integrate the testflight into the iTunesConnect. Now like we all expected, apple is going to shut down the separate service for testflightapp.com. It means, we cannot use testflight separately anymore, we have to use the testflight services only from iTunesConnect.

Apple send out email to the developers informing about this transformation. Apple clearly states in this mail that the testflight service will no longer be available after February 26 2015, giving one month grace period for the developers to do the transition.

We can export all our testers from our testflight to the iTunesConnect. The mail also contains the steps to do this. The contacts are exported as a CSV format like "First Name - Last Name - Email" format. You can also export the device list, but there is no need for that with the new iTunesConnect pre-release feature.

In case you still need a service exactly like testflight, there are some alternatives. You can try installrapp.com, http://app.io, http://hockeyapp.net.

How to export testers from TestFlightapp.com

1. Sign in to the TestFlight Dashboard at testflightapp.com
2. Navigate to the "People" tab
3. Check mark the teammates you would like to export
4. Open the "Actions" menu on the right side of the teammates list
5. Select "Export Contact Info" to download the exported CSV file

How to import testers into the new TestFlight Beta Testing

1. Sign in to iTunes Connect at itunesconnect.apple.com
2. Click "My Apps"
3. Select the app you want to enable for beta testing
4. Enter the "Prerelease" tab and select "External Testers"
5. Click the plus sign to add new external testers
6. Use the "Import File" from the "Add New External Testers" page to upload the exported CSV file

Using Souce Control in the projects. (Xcode, Eclipse and Visual Studio.)

Souce Control is available with Xcode, Eclipse and Visual Studio.

Visual Studio: http://blogs.msdn.com/b/visualstudioalm/archive/2013/01/30/getting-started-with-git-in-visual-studio-and-team-foundation-service.aspx

Eclipse: http://www.vogella.com/articles/EGit/

What is Souce Control?

 Souce Control is the management of changes to documents, computer programs, large web sites, and other collections of information.

https://en.wikipedia.org/wiki/Revision_control‎

Why Use Souce Control?

When working on a software project, it can be very useful to use software control management (SCM) to keep track of changes in the code and coordinate work groups. An SCM system, also referred to as source control, saves multiple versions of each file on disk, storing metadata about each version of each file in a location known as an SCM repository.

Uses of Souce Control:

1) Keep the track of changes made to your project

2) Revert back to your old code in case of major issues.

3) When working with a team, source control is very useful.

4) Can push the new code to someone's machine

5) Can work with the major changes without affecting the current code.

6) Always keep the clean master copy of your project.

7) No need to take back-ups

8) We can get to know each and every line is added by who/when

9) Can store a secure copy of the project in the server.

http://msdn.microsoft.com/en-us/library/vstudio/ms181368.aspx

There are a lot of Source Control software available as free source as well as paid.

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Of all these, Xcode have the built in Source Control systems : Git and Subversion (SVN).

Subversion (SVN) need a remote server whereas Git can be worked in local itself (but also can be connected with server when need).

How to create Git for a Xcode project?

1) If you are creating a new project, the Xcode will ask something like "Create  local git repository for this project" when you choose your project location. Check that check box to create git for your project

2) If you want to create Git for your existing project, then you have to do something in the terminal. Run the following commands in the terminal.

   cd drag/your/project/folder/in/the/terminal

   git init (Create local git in the folder)

   git add . (Add all the files to the Git)

  git commit - m "Initial Commit (You can enter anything here)"

The following terms are used in Xcode while using the Git

Clone:

Use this when the master project is in the remote server and you want to download a copy of the project (called working copy) into your system

Commit:

You have done working with the local project (working copy) and you want to add all the changes with the Git (local repository)

Push:

You have done committing, and now you have to push the latest commits to the server.

Pull:

Someone in your team have pushed the latest commits and you want to download the latest changes to your local working copy.

Track Branch

Clone a particular branch into your local Git from remote Git

Merge:

When you have done working with your temporary branch you can now merge all the changes to the  master branch

 or any other branches

For more details about this topic, please refer the following links.

http://www.raywenderlich.com/13771/how-to-use-git-source-control-with-xcode-in-ios-6

https://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode_User_Guide/085-Save_and_Revert_Changes_to_Projects/manage_project_changes.html