TimeZone.currentĀ on iOS

Where does a value for TimeZone.current (https://developer.apple.com/documentation/foundation/timezone/2293341-current) come from in Swift? I spent some time on checking that this weekend. A list of the time zones changes at least several times a year, it’s not constant. There is this article https://zachholman.com/talk/utc-is-enough-for-everyone-right that explains the “why” for that in a very nice, fun and detailed way. I really recommend reading that article! It’s quite long but super interesting šŸ˜€ The time zone list changed on the 4th September 2024 last time (https://www.iana.org/time-zones) so just a bit over 3 months ago. So maybe TimeZone.current makes some network request to check a current version of that database? What if a user’s device isn’t connected to the Internet? What’s a default value then?

Let’s have a look at the Foundation framework’s source code here https://github.com/swiftlang/swift-corelibs-foundation and more specifically saying an NSTimeZone.swift file. So there is this line

_timeZone.abbreviation(for: aDate)

there which – if we follow a chain of calling the functions – calls a C function called __InitTZStrings() from a CFTimeZone.c file later on. And now, what does __InitTZStrings() do?

static void __InitTZStrings(void) {
    __tzZoneInfo = CFSTR(TZDIR);
    __tzDir = TZDIR "zone.tab";
}

It creates a path to a file with the time zone list! That’s it, we found it!! šŸ’ƒ So there is a constant value for a directory path called TZDIR and its value is the following (you can find it in the same file, CFTimeZone.c):

#define TZDIR	"/usr/share/zoneinfo/"

and then a zone.tab filename is just appended to that path so the answers to the questions that I put at the beginning of this blog post are:

  1. TimeZone.current doesn’t make any network requests to get an updated list of the time zones.
  2. Apple keeps that value in a /usr/share/zoneinfo/zone.tab file on iOS.
  3. Given point 2 – if you don’t update a version of the iOS system on your iPhone – you may have an outdated time zone list on your phone.

We may just try to answer the very last question in this post: what is a .tab format?

The .tab format on iOS refers to the tab-separated values in a text file, represented by the UTTypeTabSeparatedText (https://developer.apple.com/documentation/uniformtypeidentifiers/uttypetabseparatedtext) identifier in Apple’s frameworks. That type of a file contains data where fields are separated by the tab characters (\t). That format is widely supported across the iOS, iPadOS and macOS apps for handling structured data and it’s often used for the spreadsheet exports or data transfers.

Mowyty is live šŸ„³

We did it! Mowyty – an app that will help Ukrainians to start their new life in Poland just landed on Google Play (https://play.google.com/store/apps/details?id=com.mowyty.app) and App Store (https://apps.apple.com/us/app/mowyty/id1622156106) šŸŽ‰

Mowyty in numbers so far:
– 11 months since the first push in a git repository,
– 16 people worked on Mowyty so far,
– 1 burnout that I had on the way,
– 2 platforms: Android and iOS,
– 1 codebase: Flutter,
– 23 followers on our Instagram profile so far (https://www.instagram.com/mowytyapp).

Mowyty wouldn’t be live now without help and hard work of everyone who contributed with their development, design, translation, legal, marketing and other services. Special thanks to the PettersonApps and Perpetio teams andĀ my friend UlaĀ – I’m sure that without your help and support I would give up on this idea a few months ago šŸ™‚

It is just a beginning of course. We want to listen to feedback from our users and keep improving the product. If you have any Ukrainian friends for whom the app may be useful please share the links with them šŸ™‚

iOS Developer ā€” preparing for a recruitment process, part 2: technical screening

This is the second article from my ā€œiOS Developer ā€” preparing for a recruitment processā€ series. You can read the first one about writing a good CV here:

iOS Developer ā€” preparing for a recruitment process, part 1: CV

In this part, Iā€™m going to cover the first stage of a recruitment process which is a technical screening. Itā€™s usually a short (20ā€“50 mins) call with a recruiter from a company that you applied to or a recruiter from some agency working for that company.


During that short call you are going to talk about the following topics:

  • recruiter and company introduction,
  • your introduction,
  • your CV walkthrough,
  • your motivation for applying to that company,
  • your questions.

Recruiter and company introduction

At the very beginning a recruiter will introduce themselves and a company / position they are recruiting for. Remember to do your own research beforehand anyway. You will get to know how the recruitment process in that company looks like, how many stages there are etc.

Your introduction

You will be asked to quickly introduce yourself. Your answer shouldnā€™t be very long and detailed at this point. I recommend to say that you are an iOS developer, youā€™ve been programming for X years, using Swift and / or Objective-C programming languages, you can mention your experience with other platforms (backend or Android for example) as well and at the end I would say what company you work at currently and what your role is.

Your CV walkthrough

You will have an opportunity to go a bit more in depth in terms of your experience and career so far. Try to highlight the most interesting technical challenges that you have faced at each of the previous companies (and at the current one too of course) but also remember to choose the most relevant ones for the position you applied for.

Your motivation for applying to that company

This is a very important question. The first one from a ā€œcompany culture fitā€ series. There will be another recruitment process stage dedicated to this topic later, where you will be asked more questions checking if your personality matches what they company is looking for. There is no one-fits-all answer to this question. Try to show that you share companyā€™s values, that money is not the most important factor for you while looking for a job. There is always someone who will be willing to pay more than your current company. If that is your main focus, that means you will easily leave the company even in a few months which is a red flag for a recruiter šŸ™‚

Your questions

This part is usually left for the end of a technical screening but it doesnā€™t mean itā€™s the least important one. It is actually important. Asking questions about a role and a company shows your interest, your excitement, that you are really interested in that position. I remember myself looking for the first job some years ago and answering that question ā€œNo, thank you, I think I have no questions at this point.ā€. I know how wrong that was now, after 8 years, and it was definitely a red flag for the companies back then.


Thatā€™s it for this part of my ā€œiOS Developer ā€” preparing for a recruitment processā€ series šŸ™‚ I hope you learnt something new while reading it. I will publish the next part about a technical interview, including a list of the iOS topics that you may be asked about (all iOS developer levels, from Junior to Senior) in more or less a week.


If you liked this article and the series in general and would like to be updated once I publish the new articles, feel free to follow me on TwitterĀ https://twitter.com/dmarkowski_Ā and add my blogĀ https://damianmarkowski.com/blog/Ā to your bookmarks. See you next time šŸ‘‹

iOS Developer – preparing for a recruitment process, part 1: CV

We all know that preparing for an interview in a tech industry is not easy. There are so many things that you can be asked about, regardless if you are an Android, iOS, backend or web frontend developer.

I have decided to write a short series of articles, explaining ā€” based on my experience and knowledge ā€” how to prepare for a recruitment process as an iOS Developer. Even though one of the next articles will be focused on the technical iOS development related questions that you may be asked, some of the content in this series will be useful for the other developers as well.

This is the first article in this series and itā€™s gonna cover preparing a good CV.


Let me just set the expectations straight from the very beginning ā€” Iā€™m not going to provide any CV template in this article. Instead, I will try to give you some advices that will help you to prepare a successful CV.

In my opinion, there are two types of CVs, or in other words ā€” two groups of developers that need to create their CV: 1) junior developers or people aspiring to be developers (without a professional experience yet) and 2) experienced developers (applying for regular / senior positions).


CV for inexperienced / junior developers

If you are in this group, donā€™t worry, all developers had to start somewhere, we all have been there. I think it might be helpful for you to consider the following suggestions while creating your CV:

  • Itā€™s ok not to have any professional experience at the beginning. Feel free to add GitHub, App Store links to your personal projects and apps. It shows that you like trying and finishing projects. It also shows that youā€™ve run through the whole process of releasing an app to the App Store, that means a lot.
  • Contributing to open source projects counts as well, actually itā€™s really beneficial to mention that.
  • Itā€™s also a good idea to mention all the courses or certificates that you have completed. They donā€™t need to be directly related to an iOS development. For example if you are applying for a job in Sweden as a foreigner, it will be much appreciated if you have done a Swedish language course.
  • Because you donā€™t have any professional experience yet or itā€™s just one company, it might be worth adding an information about being a part of some studentsā€™ organisations or some local communities. That positions you as a potential leader, passionate developer, someone doing ā€œsomething moreā€ than a minimum required daily work.

CV for experienced developers (applying for regular / senior positions)

If you are in this group, try to choose only the most relevant experience and skills to the position that you are applying for. Iā€™m sure you could have a nice 5-page long CV with all the projects, companies that youā€™ve worked for, all responsibilities described in a detailed way but a sad reality is thatā€¦. the recruiters wonā€™t have time to read all of that. Try to focus on the following suggestions:

  • Recruiters like numbers while reading about your experience. Make sure you use them while shortly describing how you contributed to your teamsā€™ successes. Bullet point lists and numbered lists work better than a plain English descriptions.
  • Include only the most relevant experience, information about frameworks that youā€™ve used, programming languages, projects. It should be as relevant as possible to the job position you are applying for.
  • You probably donā€™t want to use a lot of space in your CV for your hobbies or non-job related things. Recruiters are looking for as many proofs as possible that you are worth that higher rate for a more senior position.

Bonus šŸ„³

I mentioned at the beginning of this article that Iā€™m not gonna include any templates for a CV but thatā€™s not entirely true actuallyā€¦. I would like to share with you a nice tool that I find really useful for creating CVs. Itā€™sĀ https://www.overleaf.com/. Itā€™s a LaTeX based platform. They have some templates to create a CV as well. Check them out!


And this is the end of the first article in this series. In the next one I will write about preparing for the first stage of the recruitment process: a technical screening.


If you liked this article and would like to be updated when I post a new one, feel free to follow me on Twitter:Ā https://twitter.com/dmarkowski_. See you next time! šŸ‘‹

New year, new Quick10 šŸ„³

I prepared a small (or maybe not so small) New Year present for you! Thanks to my friend’s (she’s a product designer) work, Quick10 game has been completely re-designed. It looks much nicer now and I’m sure you are going to enjoy it even more. I also added 2 extra leaderboards (so there are 3 in total now), separate ones for Easy and Difficult levels. Happy New Year šŸ™‚

Download the latest update: https://apps.apple.com/gb/app/quick10/id1431512940

More info about Quick10: https://damianmarkowski.com/quick10

Why I stopped using SwiftUI and AWS in my personal project

At the end of March this year, when the coronavirus lockdown began, I started missing table tennis. I decided to create a mobile app for table tennis players and enthusiasts. I already have a few personal apps and games in the iOSĀ App StoreĀ but I wantedĀ ForehandĀ to be a bigger, multiplatform (iOS and Android) and long term one. Something like a personal business card for a mobile apps developer.

As Iā€™m an iOS developer, I started from an iOS app. Itā€™s 2020, Iā€™m starting a new iOS app, sounds like a great opportunity to learn more about SwiftUI I thought. So I started building the iOS version of Forehand using SwiftUI. It was going quite well letā€™s say, I added a few initial screens.

SwiftUI project structure


First problems that I faced were around a performance of VStack. I had a VStack containing 5 WebView views, each of them loading a different HTML, embedded YouTube video.

WebView which I embedded 5 times (each with a different HTML) in VStack

Putting 5 instances of such a view was killing the performance, VStack was just almost non-scrollable.


Main issue number 2 was customising a navigation bar. Navigation bar on some of the screens was supposed to look like this:

Navigation bar with a custom background colour

or like this:

Another example of a navigation bar with a custom background colour

Unfortunately customising navigation barā€™s background colour or its titleā€™s background colour is not natively supported in SwiftUI and I needed to try some UIKit-ish solutions. None of them was perfect and at some point I even ended up replacing a navigation bar with a normal View. It worked, I could fully customise it but I didnā€™t feel itā€™s a long term solution. At the end I left default colours.


The last thing that Iā€™m gonna mention in this article about problems with SwiftUI is Onboarding screen. In UIKit we do it with UIPageViewController. Unfortunately there is no built in SwiftUI component for that yet. I researched Stackoverflow what workarounds other developers do, I found a few solutions. They were based on manually calculating frames of swiped views. It didnā€™t work well for all screen sizes unfortunately so I decided to use a UIKit bridge called UIViewControllerRepresentable. UIViewControllerRepresentable and UIViewRepresentable are protocols which let you embed old good UIViewController or UIView in a SwiftUI app. So I had Onboarding screen working but there was a navigation to the Home screen after tapping a Next button on the last page of onboarding missing. In a UIKit-only app it would be an easy push(viewController) or performSegue(with identifier) but SwiftUI screens are driven by state changes so itā€™s a bit different.

I ended up doing something like this:

I was sending a ā€œNextButtonTappedNotificationā€ from Onboarding SwiftUI view conforming to UIViewControllerRepresentable and it was being received by ContentView which is SwiftUI appā€™s entry point. Not entirely clean solution but changing screens worked. There was a problem with a navigation bar though. I couldnā€™t get rid of an additional top header added by NavigationView / NavigationLink. I spent 2/3 evenings on that and taking into account previous problems as well I came to a conclusion that maybe it will be better to wait for SwiftUI 2.0 and not to spend my evenings on being frustrated and trying to fix things that are super easily achievable in UIKit. Thatā€™s why I decided to stop using SwiftUI for the first version of Forehand. I rewrote everything what I had to UIKit views in 2 days and I started progressing with the project much faster.


Most of the mobile applications need some sort of backend, some remote data provider. Forehand is not different. As I am a one-man-band (in terms of devs, because I have an awesome designer working with me on Forehand too), I wanted to go for something easy to set up, integrate and multiplatform (iOS, Android). I considered 2 options: Firebase and AWS. From my previous experience I knew that Firebase is easier to set up, you donā€™t need to deal with a maze of permissions setup but on the other hand AWS seems to be more scalable. As I think about Forehand as the app that Iā€™m gonna support and maintain for a longer time, I decided to use AWS driven backend for my app. Unfortunately I faced a blocking issue just at the beginning of the integration, at authentication stage. I want the users of my app to be able to authenticate using the following methods: Log in with Facebook, Sign in with Apple and Email + password sign in. Sign in with Apple is not only a nice to have sign in method, but itā€™s also required by the App Store review guidelines if you have any social sign in method (including Log in with Facebook) in your app:Ā https://developer.apple.com/news/?id=09122019b. Even though AWS Cognito officially supports that sign in method as per this article:Ā https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-cognito-now-supports-sign-in-with-apple/, there is still an open issueĀ https://github.com/aws-amplify/aws-sdk-ios/issues/1809Ā and people try to find hacks to make it work. I didnā€™t want to go that way, I didnā€™t want to spend my evenings on finding hacks to fix AWS Cognito bugs and thatā€™s why I decided to switch to Firebase where all sign in methods which I needed worked perfectly and the whole configuration process is really well documented.


Conclusions

  • Some of you may say that Iā€™ve given up too early and thatā€™s a fair point. I just want my free time that I spend on coding a personal app to be as enjoyable as possible. I also want to see the results as soon as possible, to touch what I build and to let other people touch it, test it, give some feedback.
  • Most of the SwiftUI issues that Iā€™ve faced are fixed in SwiftUI 2.0 which will be publicly live this autumn. There are lazy stacks, native support for onboarding-like screens and much more:Ā https://developer.apple.com/videos/play/wwdc2020/10041/. I just didnā€™t want to wait a few months for SwiftUI 2.0 to be publicly live and then maybe 2/3 months to build my app from scratch using a technology that Iā€™m not fully confident with yet.
  • In terms of a backend solution – Iā€™m not forgetting about AWS. Maybe one day I will go for some kind of a hybrid solution: Firebase managed authentication and AWS for storing and providing data – I donā€™t know if itā€™s possible though. I would need to do more research.

I hope this article will be at least a bit helpful for some of you. Please feel free to share your thoughts and experience with the technologies mentioned here.