feed.xml

<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"><generator uri="https://jekyllrb.com/" version="4.2.2">Jekyll</generator><link href="https://shurakov.name/feed.xml" rel="self" type="application/atom+xml" /><link href="https://shurakov.name/" rel="alternate" type="text/html" hreflang="en" /><updated>2022-04-01T22:03:57+02:00</updated><id>https://shurakov.name/feed.xml</id><title type="html">Evgeny Shurakov</title><subtitle></subtitle><author><name>Evgeny Shurakov</name></author><entry><title type="html">Prepare for release</title><link href="https://shurakov.name/prepare-for-release/" rel="alternate" type="text/html" title="Prepare for release" /><published>2020-02-01T12:00:00+01:00</published><updated>2020-02-01T12:00:00+01:00</updated><id>https://shurakov.name/prepare-for-release</id><content type="html" xml:base="https://shurakov.name/prepare-for-release/"><![CDATA[<p>There is more to the process of releasing an app than archiving a project using release build configuration and uploading to the store. As the app grows you want to be sure about the quality.</p>

<p>In the mobile development world delivering the app to the customer takes time. Quite some time :-) Some years ago it was multiple days or even weeks of waiting time, now it’s a bit better and usually takes one or two days (thanks Apple!). Still, if you have a critical bug in the app that you want to fix, one or two days is a lot of time.</p>

<p>I collected several ways to help to ensure the quality of the app.</p>

<!-- More -->

<p><strong>Code freeze</strong>
After code freeze and before release, modifications to the code are discouraged and normally only bugfixes would be applied. Unfinished features normally not included and stay either in their branches or hidden from the user with feature toggles.</p>

<p><strong>Internal build (Private Beta)</strong>
Private Beta is a version of the app for internal testing. If the app uses a backend, it usually connects to the beta version of the backend.
To distinguish between different versions of the app, it is a good idea to use a different bundle identifier, app name, and icon.</p>

<p><strong>Unit, UI and Integration Tests</strong>
Tests are nice to have. They can help to save time by automating common usage scenarios or finding regression of older bugs.</p>

<p><strong>Bug bash</strong>
During bug bash, a group of people tests features and bugfixes that will be released. Participants don’t need to be technical, but they do need a good knowledge of the app. It’s good to test on different phone models and OS versions.</p>

<p><strong>Check localization</strong>
Localization can be checked during bug bash or as a separate event.
Automate what can be automated. For example, check that all strings are translated while making an internal build.</p>

<p><strong>External build (Public Beta)</strong>
Public Beta is a version of the app that connects to live BE and is as close to the live app as possible. Depending on the length of the release cycle, the app can stay in public beta for multiple weeks.</p>

<p><strong>Collecting feedback, checking crash reporting tool</strong>
Feedback from users is a good way to check if things are working as expected.
Keep an eye on incoming crash reports. Is there something suspicious, are there new crashes? Depending on the severity you can decide to fix it now and send a new beta build or fix it in the next version.</p>

<p><strong>Incentives to use a Public Beta</strong>
Using Public Beta app is beneficial to you, but why would users want to be a guinea pig?</p>
<ul>
  <li>early access to new features. This one is easy, no additional work is required :-)</li>
  <li>priority support. All questions and messages from beta users can be prioritized and answered first</li>
  <li>benefits, that only exist in Public Beta version. For example, if the app works via subscription, users could get some small discount as long as they’re using the beta app and keep it up to date.</li>
</ul>

<p><strong>Staged rollout</strong>
Unfortunately, the staged rollout for iOS devices is very primitive in functionality, but still may be useful to limit the number of users updating to the latest version at the same time.</p>]]></content><author><name>Evgeny Shurakov</name></author><summary type="html"><![CDATA[There is more to the process of releasing an app than archiving a project using release build configuration and uploading to the store. As the app grows you want to be sure about the quality. In the mobile development world delivering the app to the customer takes time. Quite some time :-) Some years ago it was multiple days or even weeks of waiting time, now it’s a bit better and usually takes one or two days (thanks Apple!). Still, if you have a critical bug in the app that you want to fix, one or two days is a lot of time. I collected several ways to help to ensure the quality of the app.]]></summary></entry><entry><title type="html">Localization tips for iOS</title><link href="https://shurakov.name/ios-localization-tips/" rel="alternate" type="text/html" title="Localization tips for iOS" /><published>2020-01-01T12:00:00+01:00</published><updated>2020-01-01T12:00:00+01:00</updated><id>https://shurakov.name/ios-localization-tips</id><content type="html" xml:base="https://shurakov.name/ios-localization-tips/"><![CDATA[<p><strong>Start from day one</strong></p>

<p>Think about localization from day one, even if the app supports only one language. It doesn’t take much time but makes your life easier in the future.</p>

<p><strong>Use identifiers as keys</strong></p>

<ul>
  <li>Use identifiers that reflect the function of the element as well as its location in the app.</li>
  <li>Use the same identifier prefix for keys that belong to the same functional unit/page.</li>
</ul>

<p><strong>Write good comments</strong></p>

<p>Give the key a comment, saying where it is located on the screen, what kind of element it is, and what is the function. Describe all parameters that are used in this string. Use business terms, that is used in the app and not developers slang, cause most likely it won’t be localized by developers :-)</p>

<p><strong>Always use numbered format specifiers</strong></p>

<p>When using format specifiers, use numbered ones so that translators can shuffle them around.</p>

<p><strong>Example</strong></p>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1
2
3
4
5
6
7
8
</pre></td><td class="rouge-code"><pre>/* Action button to go to the next screen after user picks a date / Select countdown date screen / Create new event flow */
"create_event_select_countdown_date_action_button" = "Go";

/* Interval description / Select countdown date screen / Create new event flow. Parameters: %1$@ - formatted number of days (1 day, 5 days) */
"create_event_select_countdown_date_interval_description" = "Start %1$@ countdown";

/* Screen title / Select countdown date screen / Create new event flow */
"create_event_select_countdown_date_title" = "Select countdown date";
</pre></td></tr></tbody></table></code></pre></div></div>

<p><strong>Skip interface builder</strong></p>

<p>I find it very hard to localize interface builder files and storyboards.
I tried two options:</p>

<ul>
  <li>one interface file per language for the same screen is <strong>a lot</strong> of work to maintain and support</li>
  <li>using Xcode string export/import results in keys that don’t make sense and it’s not possible to add a comment</li>
</ul>

<p>My solution is to create UI elements in code or connect them from the interface file to the code and do all localization from the code.</p>

<p><strong>Provide screenshots</strong></p>

<p>Screenshots are a great way to understand the context in which strings are used. Understanding context is important to get quality localization.
Many of localization services (OneSky, Lokalise) provide a library that can take a screenshot and mark all keys it sees on it.</p>

<p><strong>Audit language files</strong></p>

<p>When making a release build, add a step to check that everything is localized. This can be done by going through language files and comparing key and its value. If they are the same, it means the localization is missing.</p>]]></content><author><name>Evgeny Shurakov</name></author><summary type="html"><![CDATA[Start from day one Think about localization from day one, even if the app supports only one language. It doesn’t take much time but makes your life easier in the future. Use identifiers as keys Use identifiers that reflect the function of the element as well as its location in the app. Use the same identifier prefix for keys that belong to the same functional unit/page. Write good comments Give the key a comment, saying where it is located on the screen, what kind of element it is, and what is the function. Describe all parameters that are used in this string. Use business terms, that is used in the app and not developers slang, cause most likely it won’t be localized by developers :-) Always use numbered format specifiers When using format specifiers, use numbered ones so that translators can shuffle them around. Example 1 2 3 4 5 6 7 8 /* Action button to go to the next screen after user picks a date / Select countdown date screen / Create new event flow */ "create_event_select_countdown_date_action_button" = "Go"; /* Interval description / Select countdown date screen / Create new event flow. Parameters: %1$@ - formatted number of days (1 day, 5 days) */ "create_event_select_countdown_date_interval_description" = "Start %1$@ countdown"; /* Screen title / Select countdown date screen / Create new event flow */ "create_event_select_countdown_date_title" = "Select countdown date"; Skip interface builder I find it very hard to localize interface builder files and storyboards. I tried two options: one interface file per language for the same screen is a lot of work to maintain and support using Xcode string export/import results in keys that don’t make sense and it’s not possible to add a comment My solution is to create UI elements in code or connect them from the interface file to the code and do all localization from the code. Provide screenshots Screenshots are a great way to understand the context in which strings are used. Understanding context is important to get quality localization. Many of localization services (OneSky, Lokalise) provide a library that can take a screenshot and mark all keys it sees on it. Audit language files When making a release build, add a step to check that everything is localized. This can be done by going through language files and comparing key and its value. If they are the same, it means the localization is missing.]]></summary></entry></feed>