Daniel Tull

The Hard Work Behind Running a Successful Community Event

2016-02-20T00:00:00+00:00

There was a mixup with the ticketing process for this week’s NSLondon event which has caused some complaints and discussion on its event page.

I ran the London iOS Developer Group (LiDG) for five years, putting on two 30 minute talks at the Apple Store, Regent Street almost every month. I never delegated out to anyone else and eventually I got really tired of chasing for presenters, chasing for slides, discussing date conflicts with the Apple Store, promoting the event via Lanyrd and twitter and still getting complaints.

If anyone thinks that organising a large meetup with informative and entertaining talks is easy, I would encourage you to try to do so yourself.

I have seen NSLondon rise up in the London iOS community from just before its inception. Daniel Haight has put in an extended team over the last year which, as far as I can tell, has only recently become fully self functioning allowing him to take some likely much needed breaks from the hell that is organising an event.

From my own experience, I can say that without this team, NSLondon just couldn’t be sustained by any one, no matter how much they loved and cared about their event.

To me looking in, it seems like the ticketing mistake this week was possibly caused by this new extended team.

I am sure the much underpressured NSLondon team will want to prevent this happening again more than any one commenting on the event page. This team is evolving, improving and learning. That’s the price we pay for continued events, because it sure hasn’t been with money over the years.

If anyone thinks that organising a large meetup with informative and entertaining talks is easy, I would encourage you to try to do so yourself. Because it’s fun, invigorating, empowering, charitable, scary, frustrating, depressing, annoying and stressful.

Not a Core Data error

2015-11-20T00:00:00+00:00

This morning I came across SQLite error code:522, 'not an error’ before seeing the app crash. Clearly not an error!

In Issues I make use of Core Data and one thing I decided early on was to use its store as a cache only: All data in the Core Data store can be fetched again from the server. There were a couple of reasons for this choice:

It keeps me flexible to model changes, without the overhead of migration.
I could store user-created entities such as favourites, draft issues and draft comments in files NSCoding, which in turn allowed me to easily adopt CloudKit.

When a model change happens, I delete the store at the URL I gave and recreate a new one in its place.

The problem above occurred for me because Core Data creates journaling files alongside the file I specify. When I delete the store, I don’t touch these files, mainly because there’s not really a way to know about them – they have the same filename prefix with -wal or -shm appended, so I could delete all the files with the same filename prefix.

An easier solution I saw was to create a directory at the URL and make the actual store inside that directory. This way, when I need to delete the store, I can remove the folder safely knowing that all the journaling files will be removed as well.

Update 26th November 2015

Pete Callaway has pointed out to me that a method called destroyPersistentStoreAtURL:withType:options:error: was added to NSPersistentStoreCoordinator in iOS 9 that deletes a store and its associated files.

This should negate the need to try to guess what extra files Core Data or SQL might create now or in the future.

It was also mentioned at WWDC this year.

Removing Crashlytics and Google Analytics

2015-11-16T00:00:00+00:00

One of the beta releases of Issues caused one of my testers to tweet:

@danielctull #238 yes!
— Lee Armstrong (@lesmond) 7 November 2015

This was in reference to a ticket I added to Issues’ tracker: #238: Remove Crashlytics.

Today version 1.1.2 was released without Crashlytics and after removing Google Analytics in version 1.1, I can now say Issues contains no tracking libraries. On Twitter this evening I received a couple of enquires as to why I had chosen to do this, so I thought I’d provide a little detail about it here.

Trust

Issues has the potential to store very private and very secret information; from amazing new features for products, damning security bugs to just embarressing mess ups. These are generally the same reasons many companies choose to host their source code and bug trackers in house, and I have taken the decision that Issues will communicate with only the servers my users trust.

I would like to just point out now that I have never ever provided either Google Analytics or Crashlytics with any data from a connected bug tracker. I used the former to track sales and which screens were being hit and the latter for crash reporting.

However, how can I expect my users to trust me on that? Trust is hard enough to win face-to-face, let alone when you’re only reading their words or perhaps have no contact at all.

If someone at a highly secure company is considering Issues, I want to make sure the only network connections from my app are to their servers.

Lets face it, both Google Analytics and Crashlytics are black boxes. Can a sole developer like myself really trust and know that they aren’t doing something that I wouldn’t approve of?

(Note that I’m not suggesting anything they may do is bad just something I might not approve of, in this particular case.)

This has honestly weighed on my mind since I released Issues.

Analytics

The reason I chose to include Google Analytics in the first place was a fear that I wouldn’t get some important data that would inform me about which decisions I should make.

It turns out users have just emailed me about what they want. Almost every request has mentioned one omission, which was cut from previous versions because of time constraints and will make it into the upcoming version 1.2 of the app.

I’ve already got a long list of features I would love to make and a vague order of their importance.

The way I had Google Analytics showed no useful data. If I spent some time to research what to track it might help me, but just tracking pages revealed nothing but vanity metrics.

At any rate, Issues isn’t an app I’m trying to encourage “engagement” in. The whole point is that you spend as little time as possible using it.

Crashes from iTunes Connect & Xcode

Recently, I’ve had a couple of reports from beta testers of crashes and Xcode has picked them up. This was the point I realised that I really just didn’t need Crashlytics.

It must be said that Crashlytics still has a superior way of viewing crashes than Xcode. For some reason Xcode wants you to select a version to fetch the crashes for that release of the app. When beta releases can be once every day or two, you end up with a lot of builds that could contain crashes.

Seriously, it’d be great if Xcode just had a list of crashes that you could then select and see what version it was, as it stands it’s quite easy to miss crashes. On the other hand, if a tester reports that build 2348 crashes then it’s easy to find. I’ve filled rdar://23559628 (Open Radar) with Apple.

Finding explicit .png references in xibs

2014-12-10T00:00:00+00:00

I have come onto a project where I have been asked to move all images into asset libraries to more easily manage them. An issue is that the project’s many xib files reference the images as image.png rather than just the image name image.

I started to go through the ~20 xib files to remove the .png at the end of the image names. But after the first xib, I got bored. So I quickly came up with the following script, which finds all the .png references in all .xib files recursively inside the current directory.

grep -r -i --include=*.xib ".png" .

This will list the files along with the line in the xib file it found, which can guide you as to where to look if it’s not obvious, as well as making sure you’ve converted all cases.

However, I had a lot of .png references to change, and given that I had just automated finding them, surely I can automate the task of removing them?

I found a solution which compromised of piping the result of my grep through sort and uniq(ue) to a perl script which replaces the first instance of .png that occurs on a line.

grep -r -i -l --include=*.xib ".png" . | sort | uniq | xargs perl -e "s/.png//" -pi

Some xib entries had two images per line, but it was simple and quick enough to just run this script again to get the second occurance of the .png.

An error was encountered while running

2014-11-20T00:00:00+00:00

Along with a lot of the rest of the iOS community, I was playing around with WatchKit yesterday, adding initial support to my app Coordination.

I have previously implemented extensions and had an issue where the app fails to launch in the simulator and on the device, with the somewhat cryptic error message “An error was encountered while running (Domain = LaunchServicesError, Code = 0).”

While I discovered the problem before, I just fixed it and carried on. This, it seems, was a mistake.

The issue is that a framework had the same bundle identifier as the app and that is not allowed as each distinct app or bundle on the system must have a unique bundle ID.

In the case yesterday I had logic that I wanted to use in the WatchKit app contained in my main application bundle. So I created a framework to put the shared logic into, which the iPhone and Watch apps would both link to and make use of.

I added a shared framework target called “Coordination Framework” but wanted the product to just be called “Coordination” so that I could import it with @import Coordination. This would contain the core logic for the app, but keep the view and interface controllers in their respective apps.

By default the info.plist gives the bundle identifier as uk.co.danieltull.$(PRODUCT_NAME:rfc1034identifier), so because of my renaming the framework product, changed the identifier to uk.co.danieltull.Coordination and you can guess what the bundle identifier of my app is!

The solution I have is simple to add -Framework to the end of the bundle identifier in my info.plist file.

I have now filed a radar to suggest that Xcode should give an error if there are two bundles in the app with the same identifier, along with a test app demonstrating the issue.

Notes on NSURLSession Task

2014-08-04T00:00:00+00:00

In an app I’m currently working on, I use NSURLSession download tasks to retrieve data from the network. I use the delegate methods so I can get notified of progress and fill in the details of an NSProgress object.

The first thing to note is that while the following method appears to be about errors, it actually gets called on the completion of a task. If the task is successful, the error is nil. This actually went unnoticed far too long, leading to duplicate parsing of the data.

- (void)URLSession:(NSURLSession *)session
              task:(NSURLSessionTask *)task
didCompleteWithError:(NSError *)error

Another issue I’ve come across recently is that, due to the former bug, I wanted a single place to handle completion of the task. So, I ended up storing the location of the downloaded data from the following delegate method call and using it in the above method to retrieve the data.

- (void)URLSession:(NSURLSession *)session
      downloadTask:(NSURLSessionDownloadTask *)downloadTask
didFinishDownloadingToURL:(NSURL *)location

This worked on iOS 7, where sometime after didCompleteWithError: the file would disappear.

On iOS 8, the file clear up happens after didFinishDownloadingToURL: and before didCompleteWithError: leading me to have completed requests with no error and no data.

Retrofitting Asynchronous Unit Testing in Xcode 5

2014-07-10T00:00:00+00:00

With Xcode 6, Apple have finally given us a sanctioned way to perform asynchronous unit tests. For more information about this you can watch the WWDC 2014 session Testing in Xcode 6 or read the new Testing with Xcode document.

Both of these show you how to adopt the new methods in Xcode 6, however some of us still need to build with Xcode 5.1 in the hope that we’ll ship before Xcode 6 is released, but may still want to test asynchronous methods now.

Previously, I’ve used techniques similar to Mike Ash’s NSRunLoop-based example to cause the test to wait for my async code to finish running, which has worked well. Using this approach, I have recreated the basics of Apple’s asynchronous XCTest methods in a project called DCTAsynchronousTesting.

The following shows how you would use this code, it might look extremely similar to examples from Apple’s documentation.

@import XCTest;
#import <AsynchronousTesting/AsynchronousTesting.h>
#import "XCTestCase+DCTAsynchronousTesting.h"

@interface AsynchronousTestingTests : XCTestCase
@end

@implementation AsynchronousTestingTests

- (void)testExample {

	XCTestExpectation *expectation = [self expectationWithDescription:NSStringFromSelector(_cmd)];
	[AsynchronousTesting performAsynchronousOperationWithCompletion:^(BOOL success) {
		XCTAssertTrue(success, @"Operation should have succeeded.");
		[expectation fulfill];
	}];

	[self waitForExpectationsWithTimeout:2 handler:nil];
}

@end

Hopefully this will help you write Xcode 6 compatible asynchronous tests until the “fall” comes.

Easier merging of Xcode project files

2013-09-05T00:00:00+00:00

A while back, I discovered a script called sort-Xcode-project-file in the WebKit project, which sorts the Xcode project by running the following command:

perl sort-Xcode-project-file [Project].xcodeproj/project.pbxproj

I started using it to make files easier to find in my projects and just nicer to look at. After a while, I discovered that it helps a lot with merging the Xcode project file. If both sides of the merge are sorted, there are fewer differences when merging, and makes almost all merges either automatic or extremely easy to tackle.

This script has helped me manage project changes with multiple collaborators, so I suggest if you’re coming across merge issues with the Xcode project, or if you’ve got some amount of OCD, you try it out. I put the script in the repository, with a bash script to make it easier to run.

Words of Warning

This script uses regex, so it’s potentially fragile and for this reason I don’t run it as a pre-commit hook. I commit my changes and then run the script and commit the sorting changes separately, just in case it destroys my project.

An annoying issue I’ve found is that when using static library sub-projects, I sometimes see a diff (as shown below) which swaps the order of a Products group containing the library’s targets. I’m not 100% sure why, I suppose that Xcode likes to sort them one way, but the script sorts another way.

This diff can come up if you don’t run the script, which I assume is Xcode modifying it to its liking, and running the sort script will remove those changes.

@@ -1154,10 +1154,10 @@
                24D1F5C316BC464B001263D9 /* Products */ = {
                        isa = PBXGroup;
                        children = (
-                               24D1F5C916BC464B001263D9 /* libDCTAuth.a */,
-                               24D1F5CB16BC464B001263D9 /* DCTAuthTests.xctest */,
                                24D1F5CD16BC464B001263D9 /* DCTAuth.app */,
                                24DAF6D7177876D300D7B93F /* DCTAuth.bundle */,
+                               24D1F5CB16BC464B001263D9 /* DCTAuthTests.xctest */,
+                               24D1F5C916BC464B001263D9 /* libDCTAuth.a */,
                        );
                        name = Products;
                        sourceTree = "<group>";

What’s even weirder is that these groups don’t seem to be part of the main project file, but are contained in the library sub-projects. Those projects are untouched by the script, but I can’t seem to locate what else this section of the project XML might represent in the Xcode UI.

Loading images in +load

2013-05-14T00:00:00+00:00

In my current app I have some UIButton subclasses which set up their own appearance, so that I can put these UIButton subclasses in a storyboard and have styled buttons.

To do this I was putting my code in the +load method so that it would get loaded without me needing to call it from anywhere else, as shown below.

@implementation DBSGreyButton

+ (void)load {
    UIImage *buttonImage = [UIImage imageNamed:@"DBSGreyButton"];
    UIEdgeInsets edgeInsets = UIEdgeInsetsMake(0.0f, 13.0f, 0.0f, 13.0f);
    buttonImage = [buttonImage resizableImageWithCapInsets:edgeInsets];
    id appearance = [self appearance];
    [appearance setBackgroundImage:buttonImage
                          forState:UIControlStateNormal];
    [appearance setTitleColor:[UIColor darkTextColor]
                     forState:UIControlStateNormal];
}

@end

Unfortunately, I discovered that the images that get loaded have the scale of 1. My solution is to have a +loadAppearance method that gets called from the AppDelegate.

Thanks to Chris Parker for confirming that “+load fires before UIApplication init so scale isn’t set up yet…

Edit: Thanks to Vadim Shpakovski for pointing out that +initialize does work for this, saying it’s “One more reason to not use + (void)load and prefer + (void)initialize to reduce launch time in some cases.

Preventing Xcode 4 on Lion reopening windows

2011-11-07T00:00:00+00:00

Xcode 4 on Mac OS X Lion reopens all the projects from the last session. This is pretty frustrating to me most of the time as I switch from working on a client app or two plus a couple of my own. I’d rather be able to quit and reopen a fresh session to work on what I want at that moment, not have to sift through four or five spaces with different Xcode projects to find the one I want… every time I switch to and from another app.

There used to be a way of preventing this in Xcode’s preference plist, but this no longer works. Instead, a solution is to set the following folder as locked, so Xcode can’t write to it to save the state.

~/Library/Saved\ Application\ State/com.apple.dt.Xcode.savedState

You’ll want to delete the contents of this, then get info and click the locked checkbox. Et voila, no more projects reopening themselves.

Thanks again to Pete for letting me know about this. He should really be blogging these little facts!