iOS Base SDK to Support iOS 7 - ios

I have just submitted my iOS 7 compatible app using the Xcode 5 GM and iOS 7 SDK GM. My base SDK is set at iOS 7 GM and my Deployment Target is set at 6.0, I am wanting my app to support iOS versions 6.0 and up. I know that those settings are correct, however I am wondering if there is anything extra I need to do so that when the app goes live it says "Optimized for iOS 7" or whatever phrasing Apple is going to use for this. Just like they did with the iPhone 5 "This app is optimized for the iPhone 5". Anybody have an idea on this?

There is nothing else you have to, or can, do. I don't know if the App Store will display something like "Optimized for iOS 7". If it does show that once iOS 7 is released to the general public, then having built against the 7.0 SDK will probably be how Apple determines whether it's optimized or not.

App icons:
- For iPhone, iOS 7 app icons have grown to 120×120 pixels, compared to 114×114 pixels in iOS 6.
- For iPad, iOS 7 app icons should measure in at 152×152 pixels, instead of the 144×144 pixels in iOS 6.
Notes: IOS 7 & 6 UI are different. You still need to support iOS 6.
All details are in iOS 7 UI Transition Guide
Things Every App Should Do
Make sure that app content is discernible through translucent UI elements—such as bars and keyboards—and the transparent status bar. In iOS 7, view controllers use full-screen layout (to learn more, see Using View Controllers).
Redesign custom bar button icons. In iOS 7, bar button icons are lighter in weight and have a different style. For some design guidance, see “Bar Button Icons”.
Prepare for borderless buttons by reassessing the utility of button background images and bezels in your layout.
Examine your app for hard-coded UI values—such as sizes and positions—and replace them with those you derive dynamically from system-provided values. Use Auto Layout to help your app respond when layout changes are required. (If you’re new to Auto Layout, learn about it by reading Auto Layout Guide.)
Examine your app for places where the metrics and style changes of UIKit controls and views affect the layout and appearance. For example, switches are wider, grouped tables are no longer inset, and progress views are thinner. For more information on specific UI elements, see Bars and Bar Buttons, Content Views, Controls, and Temporary Views.
Adopt Dynamic Type. In iOS 7, users can adjust the text size they see in apps. When you adopt Dynamic Type, you get text that responds appropriately to user-specified size changes. For more information, see Using Fonts.
Expect users to swipe up from the bottom of the screen to reveal Control Center. If iOS determines that a touch that begins at the bottom of the screen should reveal Control Center, it doesn’t deliver the gesture to the currently running app. If iOS determines that the touch should not reveal Control Center, the touch may be slightly delayed before it reaches the app.
Revisit the use of drop shadows, gradients, and bezels. Because the iOS 7 aesthetic is smooth and layered—with much less emphasis on using visual effects to make UI elements look physical—you may want to rethink these effects.
If necessary, update your app to best practices for iOS 6—such as Auto Layout and storyboards—and ensure that the app doesn’t use deprecated APIs.

Related

How to determine React Native statusbar height for iOS

In my React Native app on iOS, I want to make a <View> that wraps the status bar. Most places say that it should be 20px in height, but on the iPhone 11, for example, it seems to be higher than that. I want a solution that fits all devices.
How should I approach this?
You can's set the status bar height, this is something which related to the phone OS. If you would like to extend it, you can just add a View under it with the same color.
In order to solve iPhone 10 or greater issues you need to use SafeAreaView.
"The purpose of SafeAreaView is to render content within the safe area boundaries of a device. It is currently only applicable to iOS devices with iOS version 11 or later"

iPhone X scaling issue, can we scale existing apps to fullscreen mode without an app update

All my existing apps are not scaled to iPhone X, is there any way to make them to full screen without an update.
It will be really helpful if we don't have to go to the hassle of upgrading all the apps again.
And if not what are the options of doing it.
It is reminding me of days back to iPhone 6.
No, you can’t get your app out of letterboxed mode without at the very least updating your app to use a launch storyboard (and building it against the iOS 11 SDK).
Also, just doing that might not make your app work right on iPhone X — unless all your UI is built from only basic uses of system view controllers, you’re likely to have at least a few issues where you need to tweak your layout to respect safe areas. (Otherwise you end up with UI hiding under the notch or rounded corners.)

iPhone X specific UI API design changes required to be 100% compatible

With the new iPhone X coming, are there any UI or UI Api changes required to fully support the iPhone X?
Are there any API changes that might affect the UIStatusBarStyle / UINavigationBar / UINavigationItem / UITabBar etc.
The only significant change I see is the larger display of 145pt longer.
The only information I could find is the Apple: Human Interface Guidelines
located here:
https://developer.apple.com/ios/human-interface-guidelines/overview/iphone-x/
For native IOS app the support is already given and all the info is available on full screen(18:9). Lots of app instead still need to fully support the new format so info available on 16:9 ratio
In order to get full-screen applications you will need to recompile your apps with IOS 11 / Xcode 9.
If you use Standard UI controls you should be safe. If you use Autolayout you can utilise the new "safeAreaLayoutGuide" which will then basically help your ui design to respect the iPhoneX view port.
I found this Transcript from Apple located here: https://developer.apple.com/videos/play/fall2017-801/?time=126
"On iPhone X, people access the app switcher (indicated by the red arrow) and the Home screen by swiping up anywhere along the bottom edge of the display. An indicator at the bottom of the screen offers a hint about this interaction.
This indicator is displayed over your app's interface. You'll need to account for this when designing your app. If your app uses UIKit controls and auto-layout, designing and developing for iPhone X and our other devices should be straightforward. Standard UIKit elements such as navigation bars, tables, and collection views, automatically adjust when viewed on iPhone X. Navigation bars, tab bars, and toolbars are positioned and scaled appropriately on all iOS devices. The navigation bar's background material is extended to the display's top edge, and the background material of the tab bar and toolbar is extended to the bottom, while the elements they contain are positioned to prevent underlapping or clipping by other elements."
Basically if you use standard UIKit you have nothing to worry about.
Although Apple recommends: "Make sure that your UI displays correctly and no elements are mispositioned, overlapping, incorrectly scaled, or clipped"
If you discover issues, use the safe area guides and layout margins to correctly position UI elements.

How to simulate double-touch on home button in iPhone 6 simulator (for Reachability)? [duplicate]

The iPhone 6 Plus has a "one handed mode" that Apple describes as "Keep everything within reach" on their iPhone design page.
The mode is enabled by double touching (but not pressing) the home button. When enabled the screen shrinks to roughly half its normal height.
Is there a way to enable this mode in simulator for testing how it looks and transitions?
I'm running Xcode 6 GM and have not been able to uncover anything. Worst case, can someone post the exact dimensions on device so it can be emulated via the resizable iPhone simulator?
Update: According to John Gruber's review, the feature is available on the iPhone 6 Plus and 6, and is not a "mode" so much as a momentary shortcut. Maybe since it only lasts for one tap it won't be important to do extensive testing. He shared a screenshot showing the corresponding size difference:
The simulator doesn't seem to have this capability, but it doesn't matter since it just moves your app's entire view down and uses the home screen background to fill the top. Devs don't need to do anything to their apps in regards to it.

What's the purpose in being able to resize a form for iOS?

When designing a form for a Firemonkey iOS application, you're able to resize the form into any possible size, and even the debug shows it as so. Obviously, iOS devices have very particular screen sizes. Why is it made possible to make my form in any dimensions I want?
I haven't gotten to the point of running this on any iOS device yet. This is my very first trial building an iOS HD application using Firemonkey. It's just very peculiar why it would let me design the form to any size I wish, since iOS apps are always full-screen and aligned to fit within various device screens.
Not all iOS devices run on the same resolution.
The iPhone 5 has a different aspect ratio than the iPhone 4.
And the iPad 3 has double the resolution of my iPhone 4.
You may also show a form covering only part of the screen (arguably more useful on an iPad).
Remember that FireMonkey is not written for iOS alone, it also covers OSX. In OSX you'd want all the normal VCL/Windows rules to apply.
Still I can see the sense if you're building a email application of having multiple screens (i.e. frames/panels/etc) performing different functions.
You can also imagine a pulldown/popup (modeless please) that does searching.
If you implement that using a different form it should not be full-screen.
So yes I can see lots of uses for non-fullscreen forms in iOS.
These two panels could be implemented using 2 forms; resizing would be useful here.

Resources