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.
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.
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"?
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.
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!
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.