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.
Related
I am currently making a classic snake game app.
The app fits and works on all iPhones however when I test on any iPad the lettering is off the screen and so is the game screen.
Is there anyway to adjust the proportion or have it depend on what device you are using?
I was unable to find much help online when looking for this question. (first image is an iPhone 7, and the second is an iPad Air 2.
What you're looking for is Adaptive User Interfaces. You should be able to have different layouts for different device sizes using a single storyboard.
You can also change values programatically in your code according to the screen size.
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.)
I am new to Sketch and facing a few issues.
As seen from the pictures below when I use symbols from Sketch default iOS UI Design, why does it looks smaller than the Actual. For example, the Navigation Bar and Bottom Bar look smaller than what actual seen in many applications and even apple's applications.
I am working on iPhone 6 platform with artboard size 375 x 667.
Secondly, I'm also working on iPod Touch. Hence do I need to recreate all my designs to suit the iPod Touch environment?
Any help would be much appreciated, Thanks.
From Sketch using default iOS UI Design:
Actual:
I put all these GUI textures and texts and they look the way I want in the editor but when I ran it on my iphone from xcode it looks so different. All the GUI Textures and Texts are in different sizes and places. Why did that happen? Second question, if I have to fix it, do I have make the xcode project again and summit it to itunes connect again? Thanks.
You didn't design your GUI with multiple screen sizes in mind.
This is a basic concept in creating a UI that most tutorials will go over, including the documentation for the default GUI system.
Using absolute positions and sizes results in UI that cannot scale to other screen sizes and resolutions.
It is also common practice to provide two versions of your UI's textures, one for standard DPIs, such as those found on older Apple devices, and most computer screens, and one for ultra-high DPIs, such as those found on Retina displays.
In the editor you can get an idea of what your UI will look like with the Game View, which this tutorial goes over.
Once you have fixed your UI, you will need to make a new xcode project, and you will need to resubmit it.
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.