> "I find this funny. IOS 7 is the same as IOS 6 except for a few re-arrangements of features and a new look."
As someone who's spent the last 2 months porting code from iOS6 to iOS7, I disagree. The API changes (documented or otherwise...) are large enough that this really was more of a port than it was a simple update.
It may look like simple rearrangement (I disagree with that assessment, but whatever), but under the hood a great deal has changed.
Interesting, we had very few issues with API changes moving to iOS 7 (mainly dealing with the status bar, especially double-height, which in some places still needs an OS-specific check). All our work has been in getting the iOS 7-style UI looking right and working well. And we have code in our app dating back to iOS 3.
Depends on how stock your UI is. The app I work on is very heavily customized (e.g., lots of subclasses of UIButton, UITableViewCell, etc etc), and iOS7 broke a lot due to underlying implementation changes. We're also pretty graphically intense, so iOS7 also likewise broke a lot of optimizations.
Quick examples:
- The entire way iOS handles text rendering has changed (makes sense, CoreText), so methods that calculate text rendering now return different results than they did before. More crucially, text measurements can now return non-round numbers, so if you're using the results without rounding them off, you will get pixel alignment problems galore. Previous versions of iOS rounded off results before returning them to you (though this is not guaranteed via documentation, or even addressed).
- Text rendering has also changed, so even if you're not using the system fonts, the exact same font will render with subtly different widths and heights. In densely packed UIs this can be problematic.
- UITableViewCell's underlying implementation has changed. More specifically, backgroundView is now by default a plain white view, where it was nil before. If you have table views that are transparent, surprise, they are now all white. There are also some subtle differences that can cause trouble if you've heavily customized UITableView - I suspect personally that UITableView now has a UICollectionView (or UICollectionView-esque) based implementation (it seemed entirely separate before), since some of the behavior now aligns.
Interesting. We do a lot of custom drawing as well (like I said, our app dates back to iOS 3, so we even have a messy custom transition animation layer that wouldn't have been necessary with newer OSes) but it sounds like we've sidestepped some of the issues you've run into just by chance.
For instance, we already had custom text metrics code since our app's font is italic, and that code already rounded to non-retina boundaries. And I think nearly all our tableviews already had custom backgroundViews.
Our biggest incompatibility was a progress HUD popup that subclassed UIAlertView, and that drawing broke completely in iOS 7 (it just turned into a little blurry white bar in the middle of the screen.
- You wouldn't expect Apple to change core apps like Phone dramatically. It's a very mature feature that isn't going anywhere and is practically identical on every smartphone. You get a numpad, you get your contacts list, your voicemail, etc. All of which has been given a new coat of paint, but fundamentally hasn't changed much.
- You see deeper changes in the built-in apps that aren't quite as mature/core. There is for example a large change in UX in iOS to move away from hard, distracting transitions towards more subtle transitions that imply information hierarchy. For example if you tap on a date in a calendar, instead of hard-wiping you to another piece of UI altogether to show you appointments, it dynamically expands the day-view from the date itself. If you tap on an album in Photos it will dynamically expand that album to fill the screen with additional photos. All of this goes towards better educating the user on information hierarchy and is much, much less jarring than before. As a third party dev that's been working with Apple on iOS7 prep, I know for a fact that they're pushing this new UX hard - you will see more 3rd party apps go towards this model in the coming months. You see some uses of this in first-party apps, but users will notice most when 3rd parties start adopting this.
- Many of the most substantial changes are under the hood and aren't being (visibly or ostentatiously) used in the stock apps, mostly because there really isn't a place for them. They will, however, power a new generation of apps in the coming months - things like a new backgrounding model will let apps do more while not in use, and also in some types of apps greatly reduce the loading/refresh time when you return to them. Or even more subtle things like dynamics, which will make scrolling feel very different in apps.
In short, users will feel some of these changes immediately, but ultimately the deep changes in iOS won't be felt until third party dev adoption is there.
They don't know anything about it. But a lot of new APIs were made available to developers that will make great apps easier to make. I think that's better for users than a new OS toy.
As someone who's spent the last 2 months porting code from iOS6 to iOS7, I disagree. The API changes (documented or otherwise...) are large enough that this really was more of a port than it was a simple update.
It may look like simple rearrangement (I disagree with that assessment, but whatever), but under the hood a great deal has changed.