On one hand, I’m extremely impressed with the stuff Apple introduced. There are very important and good API changes that are introduced, things that would help me and fellow developers make much better apps.

On the other hand…visual changes are…appalling, simply shockingly bad. This, from a company universally hailed as masters of making things that create emotional connection. Starting from lock screen, over the app icons and to the way UI controls are done, it’s heartbreaking.

When I think about user experience, I see it consisting of three important parts:

1. how it works
2. how it feels
3. how it looks

This is not accidental ordering. From 1 to 3, it defines the weighted importance of long-term success of any human interface. It’s most important that it works well, that has a good basis to build on, so it can be slowly and iteratively perfected over time. It’s important that it feels natural and delights people over time while they discover how it behaves like a natural extensions of their actions and reactions. It’s important that it looks good, because we, humans, responds most positively to pretty things, with just the right amount of polish.

In that previous paragraph, lies the major issue with iOS 7 as it exists today. We, as humans, judge things in inverted order - from 3 to 1. We must like what we see at the first split-second, otherwise we tend to disregard the thing. And thus fail to discover the inner beauty.

I feel like Apple spent 99% of the time on the important metrics that will define the next decade of iOS, on works/feels parts. And 1% on the looks part.

I’m probably wrong, but that’s how it feels to me. From all that I saw in the WWDC videos (under NDA, so can’t really tell much) they wonderfully succeeded with 1/2. The API changes and new stuff that are introduced are great, building on amazing stuff done in iOS 6 (collection views, auto layout etc). The dev tools are improved and fixed in ways that took away the most troubling parts of the everyday development life.

The beauty and the feel of the animations and transitions more than once made me to jump with joy. I smiled like a kid in a candy store every time a transition happened from starting/closing an app, inter-app navigation, inner-app navigation between views etc. It’s really, really well done.

But those are all fleeting moments. The majority of time, I, as customer, am looking at these poor app icons:

And these wireframe-ish in-app icons (will 3rd-party service’s icons be auto-processed into this?):

And this terribly illegible UI:

And this inconsistently applied HIG direction:

And these garish line icons that poke me in the eye all while claiming they are done this way so they emphasize the content:

At first, I thought these are temporary stuff, part of beta 1. After all, it may look horrible but it’s important that developers get their hands on iOS 7 so they can prepare their apps. But then I realized that this is used in promotional videos on apple.com. This is used and details are specified in iOS 7 HIG. That they actually changed app icon’s corner radius and size (for the worse) which is not something you waste your time on is this is only temporary.

I now think this is here to stay for years to come, which is making me really sad.

Did it have to be this way? Absolutely not and few good souls used couple of hours or a day and showed what you could do with just a little more care.

For goodness sake, just look at the maps example and tell me which one of the toolbar/navbar feels more natural. The app icon grid is beyond commenting - example on the left is more consistent, better looking and with perfect corner radius for the icons.

Apple set fire on the last 6 years of iterations and started from new. They could have taken a bit more time and start from a much better position than this 3-yo children’s scribble book. Whoever pushed for and decided this is the proper way to go is not fit for the job. Apple has managed to move from the best looking mobile OS on the market to worst looking one, by a whole mile.
This is the current state of the market:

Now you tell me, honestly - if you knew nothing of the market and you are a feature phone customer going to get a new phone in the store - which one of the above would you choose?
Honestly?

For more perspective, agreeing and disagreeing with me, read these:

• MacStories, by Federico Viticci
• Craig Hockenberry
• Frank Chimero
• Stephen Hackett
• John Gruber
• Mike Rundle
• Ryan Katkov
• Entropy
• Jared Sinclair
• Chris Clark
• Ian Storm Taylor
• iMore by Rene Ritchie

Even people that are defending the iOS 7 visual changes, people that say this is how Apple rolls, compare it to OS X and iMac reboots - no one, and I mean no one is saying that they love the new looks. Can you remember a successful Apple product where even their most hardened supporters felt like that..?

Update (late evening of Jun 12): Matthew Panzarino just posted an amazing article at The Next Web, with several details that finally make sense in this whole mess:

• previous Apple UI team had no say about the iOS 7 UI guidelines
• those were done by marketing/print people and possibly even former Color team

I’m lost for words. Jiminy!

On iOS though, screens were smaller in the beginning and different UI concepts were dominant thus I mostly forgot about this. Until recently, when I had the need to implement a multi-part filtering component for an iPad app I was creating.

So, RTFlyoutMenu was born.

How it works

Basic idea is this:

• Show a list of main items, which are filter categories.
• When user taps any of them, show a list of sub items (filter options).
• When sub-item is tapped, replace main item with it and close the submenu.
• Main item is shown at the bottom of the submenu, so you can reset back to default.

Thus better name is maybe RTFilterMenu, but I started with fly-out and left it as such. How it works in the end depends a lot on how you implement delegate methods, so it can be both filter and/or a menu.

What I needed for this particular instance is to quickly filter a very large catalog. In practice, this works extremely well to narrow down to just items of particular materials, colors, seasons etc.

Implementation

I modeled it per UITableView and its friends. So you have RTFlyoutMenuDataSource and RTFlyoutMenuDelegate.

Data source is self-explanatory. You define main-level items and then sub-menu items for each of them.

1
2
3
4
5
6
7
8

@protocol RTFlyoutMenuDataSource <NSObject>

- (NSUInteger)numberOfMainItemsInFlyoutMenu:(RTFlyoutMenu *)flyoutMenu;
- (NSString *)flyoutMenu:(RTFlyoutMenu *)flyoutMenu titleForMainItem:(NSUInteger)mainItemIndex;
- (NSUInteger)flyoutMenu:(RTFlyoutMenu *)flyoutMenu numberOfItemsInSubmenu:(NSUInteger)mainItemIndex;
- (NSString *)flyoutMenu:(RTFlyoutMenu *)flyoutMenu titleForSubItem:(NSUInteger)subItemIndex inMainItem:(NSUInteger)mainItemIndex;

@end

Delegate methods tell you what user has tapped and thus you can respond to those changes.

1
2
3
4
5
6
7
8

@protocol RTFlyoutMenuDelegate <NSObject>

@optional
- (void)flyoutMenu:(RTFlyoutMenu *)flyoutMenu didSelectMainItemWithIndex:(NSInteger)index;
- (void)flyoutMenu:(RTFlyoutMenu *)flyoutMenu didSelectSubItemWithIndex:(NSInteger)subIndex mainMenuItemIndex:(NSInteger)mainIndex;
- (void)didReloadFlyoutMenu:(RTFlyoutMenu *)flyoutMenu;

@end

Initial setup

RTFlyoutMenu is UIView and thus you can place it anywhere you want and it will automatically try to center itself in it. By default, I place in a container view. You must have the container and pass it as canvasView to the menu itself. Here’s a crude setup from the demo app:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

- (void)viewDidAppear:(BOOL)animated {
  [super viewDidAppear:animated];

  NSDictionary *options = @{
      RTFlyoutMenuUIOptionInnerItemSize: [NSValue valueWithCGSize:CGSizeMake(22, 22)],
      RTFlyoutMenuUIOptionSubItemPaddings: [NSValue valueWithUIEdgeInsets:UIEdgeInsetsMake(10, 15, 10, 15)]
  };
  RTFlyoutMenu *m = [[RTFlyoutMenu alloc] initWithDelegate:self dataSource:self position:kRTFlyoutMenuPositionTop options:options];
  m.canvasView = self.view;

  CGRect mf = m.frame;
  CGRect cf = self.menuContainerView.bounds;

  // center menu in container view
  CGFloat newOriginX = (cf.size.width - mf.size.width) / 2;
  CGFloat newOriginY = (cf.size.height - mf.size.height) / 2;
  if (newOriginX > 0) mf.origin.x = newOriginX;
  if (newOriginY > 0) mf.origin.y = newOriginY;
  m.frame = mf;

//   m.backgroundColor = [UIColor redColor];
  [self.menuContainerView addSubview:m];
  self.flyoutMenu = m;

  // look & feel
  [[RTFlyoutItem appearanceWhenContainedIn:[self.menuContainerView class], nil] setTitleColor:[UIColor darkGrayColor] forState:UIControlStateNormal];
  [[RTFlyoutItem appearanceWhenContainedIn:[self.menuContainerView class], nil] setTitleShadowColor:[UIColor whiteColor] forState:UIControlStateNormal];

}

For the full set of options you can pass, take a look at the header file.

Improvements

There’s room for a lot more customization options (like colors, fonts etc), but this is what I needed for this particular project.

As it is, component will lightly try to fit whatever content you give it. So if your submenu has over 10 items, it will break them into columns. This is as far it goes though and will not check if all columns can fit.

On interface rotation it will recenter main menu, but any open submenus will remain where they were, which is not optimal. Again, in my particular use-case this was not an issue (all submenus were more or less the same size and placement) so I did not work on it.

And so on and on. There is always room for improvement, so fork away. :)

Have you seen how the file paths look like for the files in your iOS app’s little sandbox? Something like this:

1

/var/mobile/Applications/F71BA910-A1F0-4B39-85CB-775806ACFF62/Documents/orders/1832006/1.pdf

The mistake I make is that I take this full URL and then save it into to Core Data storage or wherever (in this case, as order file path). And this will work if you never make updates to the app. However, if you do publish an update to the app, this URL will not be valid anymore.

The gibberish bit in the middle - F71BA910-A1F0-4B39-85CB-775806ACFF62 - is path that is specific to a given app version. So, when you update, your new app version will get some other string in there and all your previously saved / hard-coded URLs will be useless.

What you need to save is only the part that you control and maintain - in my case that’s orders/1832006/1.pdf. Which excludes the Documents part as well as this is automatically created by iOS for your app. Documents is one of several app directories that you can and should fetch using the provided iOS APIs. There is nothing that guaranties that in some future iOS versions Apple won’t rename Documents to something else, so you should not think it’s there to stay.

So, what’s the proper way to read/save local path files?

Apple already provides few useful functions:

1
2
3
4

//   get absolute path for your app
NSString *NSHomeDirectory()
//   get absolute path for your app's temporary (tmp) folder
NSString *NSTemporaryDirectory()

Along with this, I’ve long been using a helper NSFileManager methods that Erica Sadun wrote way back in iPhone OS 3.0 time, for her iPhone Developer Cookbook. I have updated it over time and the current version that I use is in my Github repository. In it, you will find more appropriately named methods:

1
2
3
4

//   this gives you an absolute path to YOUR_APP/Documents directory
NSString *NSDocumentsFolder();
//   this gives you an absolute path to YOUR_APP/Library directory
NSString *NSLibraryFolder();

Using Folder in the names instead of Directory is deliberate, to avoid potential App Store rejections due to use of private methods that Apple may be/is using.

This small extension also have few more very useful methods:

1
2

+ (BOOL)findOrCreateDirectoryPath:(NSString *)path;
+ (BOOL)findOrCreateDirectoryPath:(NSString *)path backup:(BOOL)shouldBackup dataProtection:(NSString *)dataProtection;

First one is simply a shortcut for the second with default values. So, what this does is - you supply an absolute folder path and it will return TRUE if it has found it (and it is a directory) or has successfully created it. In any other case, it will return FALSE.

Additionally, if you want to exclude this folder from iCloud/iTunes backups, then send NO for the shouldBackup (default is YES). Lastly, if you want to use iOS Data Protection APIs, then supply the appropriate protection level constant. These last two actions are best-effort side-effects - what happens when trying to set them does not influence the method result. This is just the way it worked for me here, you can change this as you want/need.

For example, here’s a sample folder path function I added for one of the apps I created:

1
2
3
4
5
6
7
8

+ (NSString *)RTOrdersFolder {
  
  NSString *f = [NSDocumentsFolder() stringByAppendingPathComponent:@"orders"];
  if ([NSFileManager findOrCreateDirectoryPath:f shouldBackup:NO dataProtection:NSFileProtectionComplete])
      return f;
  
  return nil;
}

On first time this is called, it will create this folder inside the Documents folder, mark it so it does not go into iCloud (don’t ask) and also to fully protect it from prying eyes. Every subsequent access to this folder will simply return its absolute path.

How do I use this new method in the app? Here’s typical (simplified) usage (order is custom object in the app):

1
2
3

NSString *fullOrderPath = [[NSFileManager RTOrdersFolder] stringByAppendingPathComponent:order.orderId];

order.finalPath = [fullOrderPath stringByReplacingOccurrencesOfString:[NSFileManager RTOrdersFolder] withString:@""];

Thus when you persist the order object, only the relevant part of the path - the part that you have control over - is saved. When you need full path again, it’s easy to recreate it.

I recommend that you create methods like this for any file resources that you often reference in your app.

My theme store is modal view controller and in its init method I got this:

1
2
3
4
5
6
7

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
  self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
  if (self) {
      if ([SKPaymentQueue canMakePayments]) {
          // set observer, to follow transactions processing
          [[SKPaymentQueue defaultQueue] addTransactionObserver:self];
      }

The trouble was, I forgot to add this:

1
2
3
4
5

- (void)dealloc {
  if ([SKPaymentQueue canMakePayments]) {
      [[SKPaymentQueue defaultQueue] removeTransactionObserver:self];
  }
}

Where it’s crashing

This is the symbolicated crash report:

1
2
3
4
5
6
7

2 libsystem_c.dylib 0x33e257ec _sigtramp + 48
3 StoreKit 0x32836792 __NotifyObserverAboutChanges + 38
4 CoreFoundation 0x374b6afa CFArrayApplyFunction + 38
5 StoreKit 0x32836762 -[SKPaymentQueue _notifyObserversAboutChanges:] + 118
6 StoreKit 0x32836452 -[SKPaymentQueue _addLocalTransactionForPayment:] + 250
7 StoreKit 0x3283594c -[SKPaymentQueue addPayment:] + 444
8 Banca 0x000f1612 -[ThemeStoreViewController buy:] (ThemeStoreViewController.m:477)

It crashes on that second line, with __NotifyObserverAboutChanges.

Why it crashes

If you look at the crash report, it crashes when customer attempts to buy the product. However, I did test it (of course) and have managed to buy a theme with no issues. This is where TestFlightapp.com checkpoints came in handy. Along with crash log above, I also have the checkpoint events I have sprinkled throughout my code. These are anonymous usage tracking calls, which helps me figure out how are people using my app.

In this case, it also helped me find the bug because - if you have set enough checkpoints - it gives you step-by-step scenario for repeating the issue.

This is the checkpoints list where the bug appears:

• 00:00:16 Passed checkpoint: (MAIN_VIEW)

• 00:00:18 Passed checkpoint: (APP_STORE_PRODUCTS_GETTING)

• 00:00:18 Passed checkpoint: (THEME_STORE)

• 00:00:19 Passed checkpoint: (APP_STORE_PRODUCTS_RECEIVED)

• 00:00:27 Passed checkpoint: (MAIN_VIEW)

• 00:00:31 Passed checkpoint: (THEME_STORE)

• 00:00:31 Passed checkpoint: (APP_STORE_PRODUCTS_GETTING)

• 00:00:32 Passed checkpoint: (APP_STORE_PRODUCTS_RECEIVED)

• 00:00:37 Crashed (Signal)

As you can see, if you open the store, then close, then open again and then attempt buying, the app crashes. Why?

Well, see the code at the start of the post - I’m adding my view controller as SKPaymentQueue transaction observer, but I was not removing it (the missing dealloc). So when you do this twice in a row in one session, StoreKit will attempt to deliver payment processing notification to current store VC and to the old one, which is released. Hence the SIGSEGV crash.

When looking at the number of store opening checkpoints versus the completed sales, I estimate I lost about 90% of sales over the last few days that the app is live.

I asked Apple for expedited review of the Banca 3.0.1, so hopefully they will do it.

This is the list I found in old notes:

• Beautiful Vine

• Inspired Vine

• Green Canopy

• Inspired Canopy

• Path by the Vines

• Vines on the Hill

• Grown by Wine

• Vigneron

• Code Burrel

• Code Cask

• Delicate Vine

• Promising Vine

• Flying Canopy

• Made by Wine

• Mobile Canopy

• AppCanopy

• Connected Canopy

• Radiant Flair

• Code Flair

• Sky Canopy

• Air Canopy

• Air Flair

• Shaded by vines

• Canopy Shade

• Hot Canopy

• Noble Canopy

• First Canopy

• Notable Canopy

• Radiant Canopy

• Path & Canopy

• Secret Path

• Secret Canopy

• Canopy Secret

• Hidden Canopy

• Hidden Path

• Canopy Trail

As you can see, I was very much into vineyards and wines, so a lot of these were attempts to combine networking and technology with vines. I eventually decided on Radiant Canopy but after only few months became aware it’s really not working and switched to Radiant Tap.

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush -dir SOME_DIR -revert-iphone-optimizations -q *.png

SOME_DIR is a destination path, something like ~/temp.

Go Couch to 5k 2.0 went live last week with much improved speed/distance tracking (way more accurate than before), full dailymile integration and improved integration with Twitter and Facebook. New version features a female coaching voice along with improved mail voice.

If you are thinking should you start running, go ahead and give this one a spin, it’s currently $2.99 on the App Store.

Hey look, I did 500+ builds for the new version. :)

Anyway, first make sure your project’s Info.plist has Bundle version (raw key name is CFBuildVersion) set to integer value, 0 or 1 or whatever you want as starting value. In Xcode 4.3 this can be set in Summary tab, the Build field, like this:

Version is what you will market to end users, what you will respond when setting up an update in iTunes Connect. Build is mostly for developers and testers, as a reference for bug tracking/fixing.

Next, add Run Script phase in the Build Phases for the main target and paste this script:

1
2
3

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

It looks like this in Xcode 4.3

Most important thing here is that this Run Script phase must be before Copy bundle resources. If you forget that, your builds will always be one step behind.

In the end, if you want to show this in your app, this is one way to do it:

1
2
3
4

[NSString stringWithFormat:@"%@ (%@)",
 [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"],
 [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"]
]

I then recalled similar account by Dan Benjamin - he also left a Macbook untouched for several weeks. The battery discharged so much that it was impossible to kick-start the charging again. He eventually had the battery replaced with new.

The recommendation is that, when you know a device will not be used for prolonged period of time, to remove the battery out (and that charge capacity should be about 40% at that point). In newer Mac portables though, battery is not removable (at least not without opening the case). Thus I assumed that this must be something Apple has thought about. A quick search offered a possible solution:

Unplug the device and all the peripherals.

Hold Ctrl + Option + Shift and Power button for 5-6s, then release them all.

Plugging back in, I was relieved to see the orange light. At first, it showed that charging would take 10h :) but after 5mins or so it got down to normal 1.5h-ish.

I prefer the sleeve case to larger bags. I want my gadgets to be fittingly protected when carried and I’ll then buy a larger bag and just throw each in.

I use Incase sleeve cases for my laptops and in fact wanted to get their sleeve for the iPad too, but was unable to order because they insist on US-based billing address for the card. In this age, that’s rather stupid and it’s hurting their business, but such as life, they sure have their reasons.

Thus after checking out few other bags, I decided on WaterField’s. They offer several bag options for iPad and after checking out each, decided on Ultimate model. I especially liked the vertical model, as I could see it fitting perfectly on the side and not dangling back and forth as I walk and getting in the way of my hands. I picked up the larger piggy back case as well, shoulder strap.

I had no problem to use my Serbian card, which was great. I was ordering about a week before the date when it needed to arrive. My cousins were in New York and the bag simply had to be there at least a day before so they could pack it up in time. The first hurdle was the email I received from Waterfield - the vertical bag was out of stock and it could be several days before they had them made. Unfortunately, this moved the delivery date past my D-day. Waterfield offered to upgrade the shipping up, with no extra charge, but it still ended up a day short. So I opted for the 2-day delivery which added 20$. As luck would have it, my cousins eventually stayed for another week, due to Iceland volcano eruption. Such as life…

The bag itself is amazing. Just as I thought, the vertical orientation is perfect and sits so good on the side that it does not get in the way at all. The fit is perfect, snug but not too tight, so it’s easy to put the iPad inside. The interior is padded with soft cloth that can wipe the iPad screen; don’t expect wonders though. In the back they added a tight pocket where you can fit a real wipe cloth, a few pieces of paper or something similarly thin.

I had this bag for over a year now, it’s looking great (especially the worn leather look it gains over time) and no defects nor malfunctions.

The bag is really sturdy and re-enforced on the edges. I can’t stress enough how important that is - if the bag is ever dropped, I’m pretty sure it will protect the iPad even from several meters high.

The piggy back case is very simple, obviously aimed for carrying the wall charger and cables and maybe few more simple items. It was one flaw though - the material it’s made from is the same as the sleeve case. When two of these rubs during walking, they make very annoying sound, especially inside the hallways where it’s sufficiently silent environment. Solution would be to have very small piece of velcro on the back of the piggy case that will attach itself to the main bag.

I plan to do this myself, once I have the time.

In the meantime, I’m using my old usual carry around little bag, which can attach to the iPad bag perfectly. This way I carry these two using one shoulder strap and I can detach the smaller bag when needed and carry just it. Perfect combination.

I’m very happy with the bag and would recommend it to any iPad owner. Without the piggy back case though, at least until Waterfield does something about the noise.

In the mean time, being so happy with this bag, I ordered a whole set of bags and sleeves for the laptops. I got the Suede Jacket sleeve case for both mine and my wife’s notebooks and also Vertigo vertical bags (seriously, don’t ever buy horizontal orientation ever).

Could not be happier with any of these and I plan to keep getting their stuff.

I’d like to create an integrated television set that is completely easy to use. It would be seamlessly synced with all of your devices and with iCloud. It will have the simplest user interface you could imagine. I finally cracked it.

Mouth-watering, isn’t it? Given the fact what was done for phone and tablets, this is beyond interesting. John Gruber, Marco Arment and John Siracusa all shared how they see this working. As usual, I agree with bits from all of the stuff they said, but not all of it (and them do not agree on all counts). There’s also an oft-linked NY Times article on Siri as the main interface for this new TV.

Here’s what I believe will be main features of the future Apple TV business.

There will be a physical TV made by Apple. Probably offered in several typical sizes, with whatever screen technology they choose for it. IT will have integrated their current little black box with the same name, or (more likely) iPad internals. It will of course have new software that will support stuff I’ll mention in a bit.

It will use a new remote based on Bluetooth 4.0 + it will have integrated Siri support. Siri will be activated either from your existing iOS device (which will previously be connected over Bt4.0 with the TV) or through a button on the new remote. The new non-IR remote will allow you to manage it from anywhere in TV surrounding, not when facing it directly (as you need to do with IR remote).

No cable cards nor anything like it, only one (or maybe few) HDMI ports so you can plug-in your existing set-top box. They can’t have all the possible content from the get-go (although I’m sure they will strive to have lots of it) so they must support existing stuff somehow. Adding HDMI ports is the easiest way and TV software will allow you to switch to that port and then simply be a screen for whatever is there. HDMI can also be used to support gaming consoles and such, but I somehow don’t see Apple caring much about that.

Channels will become apps. As Gruber points out, some content producers are already doing this. The issue here is what to do with like 100 apps or who knows how many channels exists around the world, both actual TV stations or shows produced by popular web sites (like Engadget). Well, they already have a solution for this.

Apps will be inside a new special folder I’ll call TV stand which will work exactly like Newstand does now. But it will be enhanced (probably in iOS 6) so that app icons will be live. When you open the folder, it will change from static app icons to live previews of whatever is currently broadcasted on that particular app. They already have this on the Mac - live thumbnails in Exposé.

Further, on the TV it will take over entire screen and basically look like a grid of TVs. It will have infinite scroll to support any number of apps and you could easily check out all the stations, all the shows. They might even have two folders, one for live TV and another for periodicals (TV shows and such).

TV stand will feature subscriptions just like newsstand and this will deeply integrate with  your existing iTunes season passes and what not. If they go really crazy on this, they could do their own version of what the wonderful Plex app (and Boxee and Roku and…etc) is doing right now and offer full access to everything you have through iCloud. Watch your content (both your local and broadcasted) from any device, at any internet-enabled location.

Each of these channel apps will have full iOS API at their disposal and they could create interactive content beyond anything that was possible so far. Imagine viewers calling-in over face time, real-time version of CNN’s iReport (if they choose to do that) etc.

Air Play will allow full screen gaming, basically killing off whatever gaming consoles survive until then. You will use iPhone, iPod touch or iPad as controllers and play on the TV. Alone or with friends. New APIs will enable that. Some apps already offer it (using Bluetooth) - see this demo trailer for majicJungle’s wonderful Chopper 2.

I can dream more, but this is the essence. With this, “Apple will get into your den”. Remember that one? :)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

Incident Identifier: 8B369A29-8421-4686-B1F6-9D66524937B5
CrashReporter Key:   746834fde1cb2033d4103df311e8f3b6ee9e8817
Hardware Model:      iPhone3,1
Process:         myApp [74]
Path:            /var/mobile/Applications/78EC36CC-DAF5-4910-9D60-A03DDC8E24BC/myApp.app/myApp
Identifier:      myApp
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2011-10-27 11:37:55.841 +0100
OS Version:      iPhone OS 4.3.3 (8J2)
Report Version:  104

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib            0x3657aa1c 0x36569000 + 72220
1   libsystem_c.dylib                 0x366513b4 pthread_kill + 52
2   libsystem_c.dylib                 0x36649bf8 abort + 72
3   libstdc++.6.dylib                 0x36613a64 __gnu_cxx::__verbose_terminate_handler() + 376
4   libobjc.A.dylib                   0x3548806c _objc_terminate + 104
5   libstdc++.6.dylib                 0x36611e36 __cxxabiv1::__terminate(void (*)()) + 46
6   libstdc++.6.dylib                 0x36611e8a std::terminate() + 10
7   libstdc++.6.dylib                 0x36611f5a __cxa_throw + 78
8   libobjc.A.dylib                   0x35486c84 objc_exception_throw + 64
9   Foundation                        0x3522d924 __NSThreadPerformPerform + 648
10  CoreFoundation                    0x31942a72 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6
11  CoreFoundation                    0x31944758 __CFRunLoopDoSources0 + 376
12  CoreFoundation                    0x319454e4 __CFRunLoopRun + 224
13  CoreFoundation                    0x318d5ebc CFRunLoopRunSpecific + 224
14  CoreFoundation                    0x318d5dc4 CFRunLoopRunInMode + 52
15  GraphicsServices                  0x31254418 GSEventRunModal + 108
16  GraphicsServices                  0x312544c4 GSEventRun + 56
17  UIKit                             0x319fbd62 -[UIApplication _run] + 398
18  UIKit                             0x319f9800 UIApplicationMain + 664
19  myApp                         0x00003a4c main (main.m:14)
20  myApp                         0x00003a04 0x1000 + 10756

...

Binary Images:
    0x1000 -    0x67fff +myApp armv7  <a0b39fab741e34eb831048cc752d8e0c> /var/mobile/Applications/78EC36CC-DAF5-4910-9D60-A03DDC8E24BC/myApp.app/myApp

Great. The usual reason for this is that Xcode did not find .dSYM file. This is actually really strange since Xcode has the .xcarchive, saved in its default location. But no matter what I tried, it did not symbolicate properly. One possible reason that I’ve seen people mention is that Spotlight has not indexed the archives and you can force this with this Terminal command:

1

mdimport ~/Library/Developer/Xcode/Archives/

This did not help either. I tested Spotlight and strangely it could not find the app signature (from the bottom of the crash log excerpt above):

1

mdfind "com_apple_xcode_dsym_uuids == A06EC84E-53BF-3209-8B63-C0CAEBDB45B6"

At this point I tried to do it manually and in series of attemps encountered all kind of possible issues.

First, I had a custom symbolicatecrash script in /usr/local/bin/ from several months ago. This script often changes as Apple devs fix bugs in it. While they do that and ship the fixed version with next Xcode update, good souls on the internet have already resolved the given issue. Thus at some point I downloaded one of those custom versions and placed it there. Hence when I tried to run symbolicatecrash manually, it used that version. You can check this in Terminal, by typing which symbolicatecrash - if it finds the script anywhere in your default paths, it will show it. If not, then you are ok.

Second, in Xcode 4.2, the current version of this script is at this location: /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash. Files in this private framework are not accessible from any other folder, so in order to run it manually you need to either use this full path or copy it to the folder where you acquired .crash log files are and run it from there.

Third, I extracted the .app and .dSYM file from the archive and placed in the same folder. I then tried to run the script from there, with all of these line (one by one):

1
2

./symbolicatecrash -v *.crash . > s.crash
./symbolicatecrash -A -v myApp_2011-10-27-113755_Alex-iPhone.crash myApp.app.dSYM > s.crash

None did anything differently. Things began to look really crazy at this point and I started doubting is this a crash report really from this version. Double-checked with tester, also double checked the .app.dSYM file as described here on Stack Overflow. All was fine, this was the binary used.

Forth, I tried to directly look for the given hex address in the crash log:

1

dwarfdump --lookup 0x00003a04 --arch armv6 myApp.app.dSYM

And this finally gave me what I needed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

----------------------------------------------------------------------
 File: myApp.app.dSYM/Contents/Resources/DWARF/myApp (armv6)
----------------------------------------------------------------------
Looking up address: 0x0000000000003a04 in .debug_info... found!
0x0000012c: Compile Unit: length = 0x00005a18  version = 0x0002  abbr_offset = 0x00000000  addr_size = 0x04  (next CU at 0x00005b48)
0x00000137: TAG_compile_unit [1] *
             AT_producer( "Apple clang version 3.0 (tags/Apple/clang-211.9) (based on LLVM 3.0svn)" )
             AT_language( DW_LANG_ObjC )
             AT_name( "/Users/aleck/dev/consulting/myApp/trunk/Classes/AppDelegate.m" )
             AT_entry_pc( 0x0000323c )
             AT_stmt_list( 0x00000112 )
             AT_comp_dir( "/Users/aleck/dev/consulting/myApp/trunk" )
             AT_APPLE_optimized( 0x01 )
             AT_APPLE_major_runtime_vers( 0x02 )

0x00000dc3:     TAG_subprogram [15] *
                 AT_sibling( {0x00000dfb} )
                 AT_name( "-[AppDelegate dealloc]" )
                 AT_decl_file( "/Users/aleck/dev/consulting/myApp/trunk/Classes/AppDelegate.m" )
                 AT_decl_line( 250 )
                 AT_prototyped( 0x01 )
                 AT_APPLE_isa( 0x01 )
                 AT_low_pc( 0x000039d4 )
                 AT_high_pc( 0x00003a6c )
                 AT_frame_base( r7 )

Line table dir : '/Users/aleck/dev/consulting/myApp/trunk/Classes'
Line table file: 'AppDelegate.m' line 254, column 5 with start address 0x0000000000003a02

Looking up address: 0x0000000000003a04 in .debug_frame... found!

0x00000100: FDE
        length: 0x0000000``` objective-c
   CIE_pointer: 0x00000000
    start_addr: 0x000039d4 -[AppDelegate dealloc]
    range_size: 0x00000098 (end_addr = 0x00003a6c)
  Instructions: 0x000039d4: CFA=4294967295+4294967295

Or so I thought. When I looked into my code at this line, this was in dealloc method, where NSPersistentStoreCoordinator was released. And that was really nutty place to have a bug. At this point I was completely stumped and had no idea what else to try.

Luckily in this case, tester was able to give login credentials so I could repeat the scenario using his data, while debugging the app on the device. And found that I had a badly formatted NSPredicate which worked in 99.9% of cases and this tester stumbled on 0.1% where it did not. Great find, it would be a serious head-scratcher if app went live with this.

But I still don’t understand why Xcode 4.2 won’t see the .dSYM file and while the script itself won’t symbolicate this .crash log. Honestly, I can’t help but think this is seriously more complicated than it needs be. But it is as it is. Here some other useful stuff I encountered while working on this.

Place where Xcode puts .crash logs picked from your testing devices: ~/Library/Logs/CrashReporter/MobileDevice/<your device name>.symbolicated

Various possibly helpful links:

· http://www.goosoftware.co.uk/blog/the-symbolicator-helps-those-who-help-themselves/

· https://devforums.apple.com/message/404524

· http://stackoverflow.com/questions/2697067/symbolicate-adhoc-iphone-app-crashes

If you have any ideas that could help, please write in comments.

However, Tweetbot faces quite a bit criticism that its custom UI hinders the UX of the app.

Many things have been said regarding this but I find Ben Brooks’ series of complaint posts particularly misplaced. He argues that Tweetbot’s custom UI over-compliates the things without bringing anything in. He’s wrong, especially this:

“Gestures in the case of Tweetbot aren’t adding anything to the all important UX — in fact I would think they are detracting from it by straying so far from conventional iOS norms.”

Tweetbot isn’t forcing you to learn anything new. You can use the entire app with one and only gesture every single iPhone user knows - simple short tap. Tap to reveal most-used actions over a tweet. Tap the view button to load the tweet in full-screen view and reveal additional options (conversation, related tweets, block/spam report etc).

What I would have liked is that Mark Jardine has not used an eye for this icon, but instead used the default disclosure indicator, like this:

That button moves the view hierarchy further along, so the default system icon should have been used. Apart from this small hickup, the UI/UX in Tweetbot great - lacks nothing, hinders nothing else.

Seriously, just try - you don’t have to know any of the gestures (swipes, multiple taps or long taps) to use the app. But when you do discover them, you find yourself using the app that much faster.

1. User details are one tap on avatar away, important actions over user are one long tap away

2. Actions over tweet are one tap away

3. Share options are another tap away after the previous one (instapaper, email etc)

4. Conversation is one swipe away. Related tweets (answers to the tweet) are one swipe away

5. Reply is triple-tap away (in my case)

etc. I think it’s clear - the UI is easy to use, learning curve is almost straight line (apart from that eye icon). But the UX is greatly enhanced with gestures and it brings you that wonderful feeling of being proud that you are the power user.

You should also read this feature showdown which, in its second part, shows why Tweetbot is so good. It’s great for reading the timeline and answering here and there. I can’t imagine anyone (apart from the most egoistical jerks) writing more tweets than reading them, so this is the advantage to have. The feature where Tweetbot is able to properly load the part of the timeline you may have missed during the night is invaluable to me. Official Twitter client often loads this and then loses my place where I was so I have to scroll and find the last tweet I was on.

The player was long ago out of warranty. Plus, I brought it to Serbia from UK, one of the last pieces the importer had. OPPO does have a “send it to us for repair” service, but the cost of sending to USA from Serbia would be more than the player is now worth. Plus, experience with other companies tells me that prices for obsolete (OPPO does not sell this model anymore) and out-of-warranty parts are outrageous.

So I emailed OPPO support, simply hoping for an advice what could be wrong so I can try my luck with local repair shops. I was hoping it’s simply some part of the power board. That was on Saturday afternoon (CET time zone).

This is where it becomes awesome. First, I got answer in less than 24h. Second, the answer said that OPPO can help me by sending me a replacement power board and a front-end display. Third, the price for the parts is mere $49. And then to top it off, they responded to my follow-up questions on Sunday and Monday (which was a bank holiday in US). I paid and they shipped the parts the very next day; the package reached me by the end of the week (sent by USPS).

Amazing, amazing support service, way better than I expected. I replaced the parts and the player is working as good as ever - silently and awesomely.

If you are in need of an excellent Blu-ray player, do not even think about anything else - buy one of the OPPO players they have on offer. I’m certain they are amazing just as this DVD player is. I mean, just look at the feature set, the customer testimonials and rave reviews they consistently get for their products.

We need more companies like OPPO. Kudos, masters.

Never again. I hope.

I have a new weapon against it now – it’s a wonderful thought that Wil Shipley said in an interview for Mac Developer Network podcast:

…Technology is just being too complicated. People just don’t enjoy using it, they don’t get it, they’re not getting the most out of it, they’re not able to use the feature they have and if we radically simplify it, then people suddenly get a lot more out of it.

They actually use more features if you give them less features.

MDN podcast is wonderful resource. I had a large backlog of various podcasts – this Shipley interview is in MDN Show 003 from back in July 2009 – which I have recently cleared out. I never check what is in any of the shows, I like when they surprise me. This interview with Wil is chock full of great thoughts.

Another fantastic feature of the MDN Show is World according to Gemmell where Matt Gemmell picks an UX subject and really, really hummers it down.

Note: Steve Scott, the man who ran MDN, has retired that show and now has a new show called iDeveloper Live. It’s more dynamic than MDN Show (more people) plus it’s recorded live and you can be part of it through the chat.

1
2
3
4
5

@interface EmailListCell : UITableViewCell {
  UIImageView *indicator;
}

@property (nonatomic, retain) UIImageView *indicator;

In the implementation part - since the property is retained, I automatically added this:

1
2
3
4
5
6
7
8
9

@implementation EmailListCell

@synthesize indicator;

- (void)dealloc {
  [indicator release];
  indicator = nil;
  [super dealloc];
}

This is what I usually do, mostly mechanically, to not forget to add proper releasing. And it came back to bite me this time.

It was because of the initializing code I wrote after the code above:

1
2
3
4
5
6
7
8
9
10
11

- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier {

  if (self = [super initWithStyle:style reuseIdentifier:reuseIdentifier]) {
      indicator = [[UIImageView alloc] initWithImage:widgetEmpty];
      [self addSubview:indicator];
      [indicator release];
  }

  return self;

}

When testing this table view, it would - in some cases only - crash the app, with one of these messages shown:

1
2

*** -[CALayer retain]: message sent to deallocated instance 0x5c73490`
modifying layer that is being finalized 0x713a170`

These are thrown when you attempt to access UIView of any sort that is in the process of being deallocated. Catching these things is very tricky, because the objects mentioned are already gone, so even if you setup breakpoint to objc_exception_throw, it won’t help you much.

So, do you see where the issue is? :)

I am releasing indicator view twice. First time when it is created and second time in dealloc. The latter is not needed, since all subviews of the cell’s view will automatically be released along with it. The code I wrote would be correct if the init line used the property:

1

self.indicator = [[UIImageView alloc] initWithImage:widgetEmpty];

By using self, I’m actually raising the retain count to 2, so two release calls would be fine. Thus, the proper initialization code would be:

1
2
3
4

UIImageView *ind = [[UIImageView alloc] initWithImage:widgetEmpty];
self.indicator = ind;
[self addSubview:ind];
[ind release];

And then the indicator release in the dealloc is mandatory (and also a proper way when dealing with retained properties).

iPad on the other hand has 9.7” (diagonal) with 1024x768 resolution, which gives 132ppi. John Siracusa said that next iPad will most likely have the same improvement in display rez, meaning it will have 2048x1536 - so the iOS4’ @2x API stuff work the same.

Granted, such resolution sounds ginormous - not even Apple’s latest 27” monitor is big enough to design interfaces that big. But if that really happen…

…how big the iPad would physically needs to be?

iPad has 1.33x aspect ratio and 9.7” diagonal display now. 2048x1536 and with 326ppi equals to about 9650in in one very long line, or divide again to get about 29.6in2. From there, the math is easy: 1.33x * x = 29.6, means that x is 4.71in and that physical screen size of the Retina Display iPad would be 4.71 x 6.28, or about 7.85” diagonal.

Sounds quite possible, does it not?

What I need from there is the actual RGB representation of the pixel color. To get that, there’s quite a bit of code involved. A large part of it is taken from Apple’s technical note QA1509.

Pixel color fetching is done in this if block from that article:

1
2
3
4
5
6
7
8
9

if (data != NULL)

{

    // **** You have a pointer to the image data ****

    // **** Do stuff with the data here ****

}

I picked up the code to get the pixel color from some web page I lost track of. This is the code:

1
2
3
4
5
6
7
8
9
10
11

int offset = ((w*round(point.y))+round(point.x)) * 4;

int alpha =  data[offset];

int red = data[offset+1];

int green = data[offset+2];

int blue = data[offset+3];

color = [UIColor colorWithRed:(red/255.0f) green:(green/255.0f) blue:(blue/255.0f) alpha:(alpha/255.0f)];

w is the width of one row of data, and point {x,y} is where the screen was touched. The * 4 in the first line means 4 bytes of raw data per pixel. Well, 4 bytes when your screen res is up to 160ish ppi. On iPhone 4’s Retina Display, with its 326ppi resolution, this should be 8. Which means correct code now is:

1

int offset = ((w*round(point.y))+round(point.x)) * 4 * [[UIScreen mainScreen] scale];

Welcome to wonderful world of resolution independent programming.

Recently, David Frampton posted great idea how Apple should have done this (the idea got picked by Daring Fireball, TUAW and many others). While idea is great, it’s more than doubtful that Apple would do this.

What Apple would likely prefer is that you, as developer, make an iPad version of your iPhone app and use the full capability of the device. In the process, you’ll create proper iPad icons and no ugliness then. In the Apple’s DevForums, there’s a thread with guidelines on how to populate App-info.plist file and what icon files are needed.

In there, it says that for iPhone-only apps you need to populate CFBundleIconFile key with 57px icon. However, if you move down a bit, you’ll find section on setting up universal app. Do that, even if your app is not universal and voila - iPad will use the proper icon for your iPhone-only app.

The settings above are from my Quickie to do app - here’s before and after:

Much better looking.

Quickie uses Core Data for storage and in one particular place I was comparing the NSString variable to a NSString-typed property of my CoreData class, QuickieList. Like this:

1

if (QuickieList.listName != theListName)

listName is defined as NSString and theListName is obviously that as well. In this particular instance, both of those had the value of “test”.

In the iPhone Simulator (running on 10.6.2) this comparison returned false, but on the iPhone running 3.1.2 it returned true. When changed into:

1

if (![QuickieList.listName isEqualToString:theListName])

result was the same.

Never – I repeat – never assume that simulator testing will be fine, even for seemingly small things. It can bite you when you least expect it.