FAQen
The icon of each iOS application should be made in the PNG format and in the resolution of 512 x 512 pixels. The file, generated in a graphics program, should not contain any partially or wholly transparent elements (in contrast to a Mac OS X application). The resolution of 512 x 512 pixels is required for registering an application in iTunes Connect, whereas in the project the icon will be added in many size variants, depending on the device on which the application will be installed, or on the manner of display (Menu, Spotlight, Settings).
As iPhone 4 premiered, Apple presented the Retina display in which the number of pixels is 4 times greater without a change of the diagonal of the display.
Although the resolution of the new displays in the case of iPhone 4, iPod touch 4 gen, and the following devices is 640 x 960 pixels, we should treat it, for the sake of programing, as if it were still 320 x 480 pixels. Why? The user’s fingers, regardless of whether they are touching the older displays or the Retina displays, remain unchanged – we are not able to place more functions, buttons, or information on the screen. What we can do is display incredibly smooth fonts and very detailed pictures during the watching of which the user, viewing the screen from the distance of ten-odd centimeters, will not be able to notice the particular pixels. The difference between the two types of display is not only noticeable but it is significant. Another reason for the pretending that the resolution is 320 x 480 pixels is the fact that the dimensions given everywhere are applicable to that resolution and it would be pointless to repeat the dimensions of a traditional screen and the Retina screen at all times.
To display information that exact, detailed, and smooth in the interface of the user of the application, one only has to add alternative versions of graphics files used in the application. Texts and systemic elements of the interface will be automatically displayed in the Retina version. For graphic files to be automatically displayed in the Retina display, one has to add the @2x suffix to them.
For example, if in the application a file logo.png was used, with the resolution of 45 x 80 pixels, the graphic designer must prepare a file named logo@2x.png, with the resolution of 90 x 160 pixels (45 x 2 = 90, 80 x 2 = 160).
Below we present sample sizes and names of graphic files, with their Retina versions:
- background.png 320x480 + background@2x.png 640x960
- gradient.png (80x1) + gradient@2x.png (160x2)
- plik.png (19x27) + plik@2x.png (38x54)
The sizes of graphic files in the Retina versions must always be even and twice as big as the files with standard resolution! The graphic designer, when creating the interface of the application, can first create the Retina version and then scale all files to 50% of the original size and save them with names deprived of the @2x suffix, however, in many cases such a procedure may cause the files with standard resolution to have wrong sizes, e.g. if the Retina file had the resolution of 19 x 30 pixels, then the file with standard resolution derived from that Retina file would have the size of 8,5 x 15 pixels, which is incorrect.
Although currently iPad tablets or other tablets, models of telephones, and computers do not have the Retina display, our graphics prepare your application or website in advance so that in the future you can immediately update the product for which that resolution will be available.
Like an application icon, splash screen is a special picture which should be included in every application. Its function is to give the impression that an application is started immediately after it has been switched on, even though the system must read into the memory all the files necessary for the display of the first screen before the window of the application can appear.
The impression is due to the fact that while the application is loading the user views the displayed splash screen, and when the application is ready for running the splash screen disappears, making room for the first screen of the application.
A splash screen should be as similar to the first screen of the application as possible, and it should be devoid of all dynamic elements – borders around cells of tables, texts, etc.
If the application has the upper status bar, that element should be replaced with a black rectangle in the splash screen.
A splash screen should have the following dimensions and names:
- Default.png and Default@2x.png – 320 x 480 pixels and 640 x 960 pixels (for iPhone/iPod touch)
- Default-Portrait.png – 768 x 1024 pixels (for iPad in an application run in the Portrait mode)
- Default-Landscape.png – 1024 x 768 pixels (for iPad in an application run in the Landscape mode)
If you submit your graphic files to us, you should pay attention to a few details, such as the names and the format of those files.
The best format for graphic files is PNG as the size of files in that format is relatively small, they have the full palette of colors, and various degrees of transparency of elements.
The files constituting the interface of an application should be placed in separate layers, for example, if an application has its own background and logo, the logo and the background should be two separate graphic files.
In the case of iOS remember about a Retina version in which the files are additionally marked with the @2x suffix, and similar variants are marked with the suffixes ~iphone, ~ipad, for example: logo.png, logo@2x.png, background~iphone.png, background@2x~iphone.png, background~ipad.png, and background@2x~ipad.png. Avoid the suffixes ~iphone, ~ipad, if the application is only designed for iPhone (iPod touch), or for iPad. The two suffixes are special and interpreted by the system and, if they are added, there have to be added at the end of the name, directly before the extension.
Buttons can have different states/statuses. Usually, a pushed button is dimmed, but you can submit your own look for buttons in different states/statuses: normal, pushed, blocked, highlighted.
Order the graphic files into catalogs and send them compressed, in the form of a zip archive. You do not have to copy the same file, e.g. a background, which is the same, into each separate catalog (menu, about the program, settings…). The files should have different names even if they have been put in different catalogs. Avoid using letters other than those of the English alphabet, e.g. do not use e.g. ą, ę, ö, é.
The graphic designer who is preparing the looks of an application probably cuts single elements out of a sample final screen of the application. Adding a set of such screens will greatly facilitate the creation of the visual side of the project.
On the tool bars in iOS – usually they are the top bar with the title of the program and the bottom tool bar – you can place various buttons, systemic ones and your own graphics. The graphics can be prepared both in the form of a complete button, with its own border, or in the form without a border. There are no limits except the maximum height of a standard tool bar, that is, 44 pixels.
If you want to place your icon in the tool bar, it should be made with the use of only transparency and the white color.
In the case of a default black tab bar placed at the very bottom, icons are made in yet another manner. We do not use two forms, active (blue) and inactive (gray). The system itself, using its gradients, properly colors the submitted icon for the purpose of high lighting the active tab. The icon should be made with the use of any color and the only thing that matters is the level of transparency. In completely transparent spaces there will be empty space, whereas in the completely covered places the systemic gradient will be displayed. Partially covered places will also be colored with gradient but the given transparency will be preserved.
All pictures from that category, if they do not have maximum sizes, will be centered vertically and horizontally.
Translating an application to iOS usually concerns only texts displayed in the program, however, adapting the program for the needs of the audience from a different country is not limited to that. The interface of the application, color scheme, images displayed, or the database can differ completely from the original version, depending on the regional settings selected in the device. When designing an application, one should take into account cultural differences, such as certain colors and their schemes, images, or symbols – the way those elements are selected and combined can influence the reception of the application in different corners of the world.
Translating files
Every file subject to dynamic translation must exist under exactly the same name in a specially created folder, called, for example, pl.lproj, en.lproj, de.lproj, or sp.lproj. Different files, exceptionally, are given the same names. If an iPhone, iPad, or iPod touch user selects a different language than one of the available languages, then the system will select that available language which is the most popular language in the user’s country. Usually, that will be the English language. A sample file structure can look as follows:
pl.lproj Localizable.strings Logo.png Logo@2x.png CountryFlag.png CountryFlag@2x.png database.sqlite en.lproj Localizable.strings Logo.png Logo@2x.png CountryFlag.png CountryFlag@2x.png database.sqlite de.lproj Localizable.strings Logo.png Logo@2x.png CountryFlag.png CountryFlag@2x.png database.sqlite
Translating texts
A translation of texts in an application is made with the help of a text file named Localizable.strings (character coding: UTF-16). The file consists of keys assigned to certain descriptions. The keys are the same for various language versions, whereas the values assigned to them differ. For example, a programmer who places the welcoming text on the first screen of the application will refer to the description assigned to the key WelcomeText which in the English version will cause the display of the text Welcome, inthe German version – of the text Willkommen, and in the Spanish version – of Bienvenida. The file Localizable.strings, placed in the folder en.lproj, has the following structure:
"WelcomeText" = "Welcome"; "LoginButton" = "Login"; "RegisterButton" = "Registration";
The equivalent file in the Polish version – Localizable.strings, placed in the folder pl.lproj – will look as follows:
"WelcomeText" = "Witam"; "LoginButton" = "Zaloguj się"; "RegisterButton" = "Rejestracja";
The file has the extension strings, however, it can be edited in virtually any program, e.g. the systemic notepad.
Every line in the file contains a subsequent description and has the following structure: "key" = "value";. Keys cannot be repeated in the same file. Unfortunately, lines in the descriptions cannot be broken directly, i.e. with the help of the enter key. If the description has to be broken into several lines, the lines ought to be separated with the help of the combination: "\n", for example:
"RegisterInfo" = "To use this app you need to be logged in\nPress here to register."
