MProgrammer

And maybe that the article is from 2007.

I would rather they took the fuel based component out of the ticket price, then charged you an amount at the gate based on the total weight of everything you are bringing on the plane, including yourself. Then you can pay less by bringing less, or pay more to bring more. A gram's a gram.

This reminds me of Trexels, a print created by John Martz in 2010. It's no longer available in print, but still fun to look through.

http://johnmartz.com/trexels

It says on that page what happens; they'll stop accepting builds with old SDKs, or if you haven't used the SDK before. It doesn't say at all that they will be closing their service, or not accepting builds at all. Just looks like they are deprecating their SDK.

Incorporating the SDK has always been optional.

I don't see how TF removing Android support has anything to do with them going away. I just this moment created a new TF app for iOS and got a new app token/etc. Where are you seeing this "won't allow new apps to be created"?

There's a third option: Continue to use TestFlight. There's no indication that they are going away.

User defined runtime attributes in IB are great. We use them for font name and other handy things (like CALayer attributes for corner radius, shadows, etc).

A word of caution, though. Using key paths in your categories like "fontName" is pretty dangerous. Apple could add such a property, or your users could already have one on their object, that would cause problems. I would suggest including a prefix or suffix, e.g. "cvs_fontName" similar to three-letter-prefixing.

I'll second the mention about checking the release notes of the latest iOS/Xcode beta, for those who have access. Moarfonts seemed promising, but caused nothing but problems when we tried it.

Nice site - it has the potential to be easier to use than the github graph. It would be nice to see how many commits the forks have ahead of their parent, or something like that.

Supporting iOS 6 is a non-trivial amount of work for many apps. Furthermore, you also have to test on iOS 6, and on more devices.

All that for a piece of the market that now amounts to 25% and is shrinking every minute.

Because it's a new app, and actively doing work to support anything older than iOS 7 is a waste of time.

The app is pretty bare bones, but it has promise.

Localization request: for anywhere but en_US, replace "1 mile" with "1.6 km" =)

A great way to deal with scaling assets for mobile is to create your art in a vector format to begin with. For Uncle Slam on iOS we did all the artwork in Illustrator and exported to PNG at three sizes: iPhone 1x, iPhone 2x (and iPad), and iPad 2x. The results are sharp images with the right level of detail and no scaling artifacts.

We even took the exact same artwork and made an 8 foot tall banner with it, and it looks great!

It's possible your app got rejected entirely because you didn't provide a launch image (formerly known as Default.png).

I'd echo the concern that the status bar should be visible in your app.

Another polish item: rows in the detail view controller get a selection highlight when you tap them, but don't do anything.

Apple also looks to see if there's a way to provide user feedback within the app, so you might want to add something for that.

That title here on HN is a little misleading.

There may or may not have been an API method in iOS 6 developer previews that allowed the app to provide the system with a new screenshot for resuming from background. That API method may or may not have been removed by the time iOS 6 shipped, and may or may not be back in iOS 7.

<whistles>

As for slow app startups, Apple hates that too. It's fine to show a loading screen, if there is loading to be done. Showing marketing videos and other bullshit? No. Not fine.

Apple’s guidelines have always said that developers should avoid splash screens ‘or other startup experience.’ That's nothing new, but many developers ignore it anyway.

Perhaps you could use a table view with static cells (even just one cell with everything in it) instead of a scroll view in most cases. With container views, you can make the static table view a subview of another controller easily now, too.

I think it would help a lot if broadcast were unavailable via the client-side API. Without broadcast, an attacker would have to find out usernames or device tokens to push to. I'll suggest that to StackMob and see what they think.

They're not sent "directly" -- they go through StackMob's servers. Urban Airship has a client library that can do the same thing, and it's widely used.

I can see how it's certainly possible for a spammer to do that with hackery, but there's a mechanism to revoke API keys and so forth if needed.