Which leads me to the topic at hand, one where I believe we can help. When it comes to mobile test automation, it all starts with one simple decision. Native framework or third-party tools?

What does that mean? As leading mobile platforms, iOS and Android — and their creators, Apple and Google — offer a tool for mobile UI test automation (as well as for unit tests). For Android, the tool is called Espresso; for iOS, it’s XCUITest. On the other hand, we have representatives of open source: third-party solutions like Appium or Calabash, both of which have become QA industry standards for many reasons.

Back to the decision of native vs. third-party. If you’re stuck in a position of uncertainty, the information and examples below should help.

Why Third-Party (Appium)

We’re using Appium as the third-party example because this solution has been most frequently used at STRV.

In short, the benefits are:

• It is the current QA industry standard.
• Allows for cross-platform tests.
• It comes with a big community and tons of learning materials.

According to many resources, Appium is the QA community’s favorite tool when it comes to mobile test automation. To see for yourself, try searching for Appium and then for XCUITest on Udemy. There are a few reasons for this popularity.

Firstly, Appium is the indirect follower of Selenium — Appium’s older, more mature brother. Both of these tools rely on the WebDriver API. Today, Selenium is still the no.1 used tool for web test automation, so it’s no surprise that QA analysts who had been using this tool adopted Appium when the mobile test automation trend started.

The second reason is that Appium provides the ability to write one test scenario that is executable on both Android and iOS. This is supposed to save QA analysts time when writing test cases. But the reality is often not as sweet as it may look. Only a small percentage of apps are truly identical on iOS and Android. More often than not, QA analysts must write up a lot of exceptions for the tests in order to run on both platforms. So whether or not the time saving benefit actually applies is arguable.

What I personally see as a big advantage of Appium is its community and how many learning materials are out there on the Internet. This is obviously great for the teams in which QA is not closely integrated with the developers; the community support allows QA analysts to solve a lot of the struggles and issues they come across before and during test automation, in both the earlier and advanced phases.

Why Native

After reading the section above, you might be wondering why anyone would decide to take an approach other than Appium? After all, it’s been established as the industry standard, it has a solid QA fanbase and there is a solid chance that your new QA hire will know the basic principles because he/she already knows Selenium. These are my thoughts:

• Native is much faster and more reliable.
• It allows QA analysts to use the same tech stack and language as developers.
• It provides better overall collaboration with app developers.
• The test code is a part of the source code (in the same repository).
• It is easier to integrate with CI/CD.

Running the test in native tools like XCUITest and Espresso is much faster than running them in Appium. On top of that, tests in native tools are much less flaky. The reason is that Appium is actually running on XCUITest and Espresso frameworks under the hood. And the extra layer of code — which is meant to allow you to run one test on both platforms — is actually slowing down the test execution and sometimes making tests fail for no obvious reason.

It is true that you can use many languages to work with Appium, such as Ruby, Python, JavaScript, PHP or C#. But is this what your team needs? Wouldn’t it be better if QA analysts used the same language as developers? Especially in agile teams, this is very important and crucial when it comes to the cooperation between QA and devs — which is why I see the fact that XCUITest only uses Swift, and that Espresso only uses Kotlin, as a big advantage. Can you imagine an iOS developer helping a QA analyst fix his tests written in Java or Python? A QA analyst having a different tech stack than developers is immediately anti-agile.

Because XCUITest can be run with command-line tools such as xcodebuild, you can easily plug these tests into your CI pipeline. There is no need to build a separate app or separate app structure for the UI tests, since they run with your existing app in the same way as unit tests.

Example: XCUITest on a Real Project

class LoginUITest: UITestBase {
    func testLogIn () {
        givenAppIsLaunched()
        whenUserSignsIn()
        thenUserIsSignedInAndLogsOut()
    }
    func testLogInWithNonExistingAccount() {
        givenAppIsLaunched()
        whenUserSignsInWithNonExistingAccount()
        thenUserNavigatesToOnboarding()
    }
    func testRegister() {
        givenAppIsLaunched()
        whenUserCreatesNewAccount()
        whenNewUserIsCreated()
        thenUserLogsOut()
    }

Tests consist of reusable steps. The main idea of that is to be able to reuse some parts of the test in a different test. All of the tests are isolated, meaning that they don’t depend on each other. Inside of the test, there are specific instructions which are executed.

func whenUserSignsIn() {
        XCTContext.runActivity(named: "When user signs in") { _ in
            Onboarding.getStarted.element.tap()
            Onboarding.loginButton.element.tap()
            Onboarding.topTextField.element.tap()
            Onboarding.topTextField.element.typeText("lukas.smetana@strv.com")
            Onboarding.bottomTextField.element.tap()
            Onboarding.bottomTextField.element.typeText("TestPW1")
            Onboarding.continueButton.element.tap()
            cancelNotificationScreen()
        }
    }

XCUITest also allows using XCTContext, which improves reporting and allows anyone to see exactly where the test failed in the report.

So, Should You Use Native Frameworks for Test Automation?

Test automation is inevitable on large and long-term projects. Manual testing can be highly effective on smaller projects and at a smaller scale but, as the project grows, manual testing gets very time-consuming and therefore costly.

The best thing about automated tests in XCUITest is that everyone can run them — developer, product owner and anyone on the client-side. This allows every stakeholder to have a real-time idea of the current application state.

There is no right or wrong answer when it comes to which automation framework you should choose. These are just ideas and thoughts based on the QA experience we’ve had at STRV. While there are teams that choose to select one framework, there are many teams that will combine two. So, whether you should use Espresso, XCUITest and/or Appium depends on your needs. Make sure to really understand what your project requires, discuss with experts if needed and go from there.

If you Google “How to become an iOS engineer,” you’ll find hundreds of resources of all kinds. Videos, articles, offline gatherings, boot camps. Some are very technical, some are more superficial but motivational, some are personal and others are just empty marketing phrases selling you some super expensive courses. So, why another article?

When I started my iOS journey, these resources helped and motivated me to read or watch stories of other human beings struggling with a similar set of obstacles and problems, and overcoming them. And that’s exactly why I decided to put this little article together.

Disclaimer: Learning Resource Paralysis

An important disclaimer that I want to emphasize at the very beginning is that as with every other “How to become” piece of content, this article is strongly subjective and might not apply to everyone. The fact that you may take a different approach to your learning doesn’t mean you are doing something wrong.

I have an urge to highlight this because, from my experience, beginner engineers often struggle with decision paralysis from all the learning materials and resources that are available, and that causes them to never start deep learning of a given subject. So, again: If you haven’t taken a single course or used a single resource I mention here, it’s okay. There are almost endless opportunities.

Is It a Good Idea to Learn iOS Development in 2023?

Let’s start from a different angle. Does it still make sense to start with iOS development in 2023? The same question occurred to me in 2019 when I was beginning my iOS journey. I came across a few videos and articles questioning whether it makes sense to learn native mobile development in the age of emerging cross-platform solutions like React Native or Flutter.

Nobody wants to spend months of hard work on studying and learning a platform that is in decline, right? Other thoughts might be whether you should choose to learn something completely different, cool and trendy, something like VR development, blockchain engineering, etc. Shouldn’t you be worried about a future in which mobile devices are replaced by augmented reality wearables?

These are all good questions. The truth is that mobile development is really already a standard software development branch and was new (and trendy) 10 years ago. I also don’t know what the future holds and what big tech companies are working on in secret. But I do have some ideas and key points that might calm you down.

1. Cross-platform apps won’t replace native iOS apps. They have their place on the market. In some cases, it is the right decision to go with cross-platform apps. But that doesn’t mean that the majority of mobile apps won’t still be native. Dig deeper into cross-platform vs. native with this video.
2. Humankind is not giving up on phones yet. Apps aren’t going anywhere anytime soon.
3. Even if mobile usage/mobile apps start to decline, the good thing is that you’re already in the software development world and can transform to backend, web frontend or any of the currently trending branches easier than before. Has Apple finally released the long-awaited AR glasses? Great, you can immediately start with ARKit, and the transition will be easier because you already know Apple’s ecosystem. You can also develop for Apple Watch, CarPlay and, potentially, any other device produced by Apple. And we can be sure that Apple won’t let any (hype) train leave without being aboard.

Is a Computer Science Background Needed?

Alright, let’s stop with the philosophical musings about the future of mobile and, instead, focus on the learning path itself. For me, in the beginning, another important question was whether I need to have a proper computer science background. The quick answer is: No, you don’t need a computer science degree to become an iOS engineer, but I strongly believe that at least some basic CS knowledge is very helpful. For that, I recommend an amazing course by Harvard CS50’s Introduction to Computer Science.

CS50 is amazing for multiple reasons. The main one for me is Professor David J. Malan because he’s just a great teacher who can explain every topic interactively and excitingly. The course itself is about general CS concepts, algorithms and data structures. You will use the programming languages C and Python to solve various tasks, such as ordering an array of elements without out-of-the-box functions, updating the RGB schema of every single pixel in the photo to apply an Instagram-like filter and much more.

The syllabus is slightly changed/updated every year. When I was doing CS50 in 2019, the last week of the course was dedicated to iOS development. It seems that, for this year, there is no major part of the course focused on that — but I still highly recommend it.

UIKit or SwiftUI

Apple offers engineers multiple ways to build iOS apps. For the UI frameworks, engineers choose whether they build their app with older and more robust UIKit or newer, trendy but, in some cases, not finished SwiftUI. This article is not meant to describe their differences, pros and cons. I want to try to help with deciding on whether you should start learning the older UIKit or jump right into SwiftUI.

Many students might think that newer is better. Isn’t the newer SwiftUI the future? I think it is. But is it a strong enough argument to skip learning UIKit? I don’t think so. Even though you can find iOS beginner courses and boot camps entirely taught in SwiftUI, I still think it’s better to start with the “old” way of developing an iOS app — and that’s UIKit. Why? Simply because the chance of working with UIKit code this year, and next year, and even the year after is still pretty high.

Maybe you will join a startup company that started developing their app entirely with SwiftUI but chances are that, as a junior iOS engineer, you will work on an already-marketed app that will very probably be written with UIKit. Companies usually don’t decide to rewrite their whole app just because a new technology was released to the market. From my personal experience with the project I am working on right now, SwiftUI is not yet fully ready to be the only UI framework for complex production apps. So we use both SwiftUI and UIKit within one project.

I took the approach of starting with UIKit and then moving to SwiftUI, and I don’t regret it. Even though I do work mainly with SwiftUI nowadays, the base knowledge of the UIKit framework is crucial for my work. And truth to be told, I think that once you’re familiar with UIKit, the learning time needed for SwiftUI will be much shorter. It’s not the fastest way of learning iOS development but, in my opinion, it’s the right one.

Getting Into the iOS World

Okay, so you passed your CS intro class (or not) and are now ready to jump into the iOS world. There are two resources I would recommend for this phase.

• Complete iOS App Development Bootcamp, by Dr. Angela Yu
• 100 Days of Swift, by Paul Hudson

Let’s talk about them a bit more in detail. The Complete iOS App Development Bootcamp and its creator, Dr. Angela Yu, is probably the course and person that were mentioned every time I was talking to junior engineers or someone who was just learning iOS. With over 74k ratings and 4.8 stars on Udemy, it’s easily one of the most popular courses.

Dr. Angela does a very good job of introducing you to the world of iOS development from the very beginning. But her course is not just full of technical stuff; she also adds a lot of “soft” topics to keep you motivated to learn. During the course, you will build many different apps. Very soon, you’ll start integrating backend API requests, etc. Even though the apps you build are always just one use case app, you will quickly get into real-world use cases — like integrating Firebase into your app or saving data locally with the Core Data framework.

There are also topics that I think are not necessary for a beginner iOS engineer, such as ARKit or Apple’s machine learning framework. If you fancy, try these lessons as well; it’s a fun thing to have an app that can recognize what is in the picture, etc. But don’t feel like you have to complete 100% of the course.

After the course from Dr. Angela, you are on a really good track to becoming an iOS engineer. You might feel like it’s time to move to the next step, to more complex topics. However, I strongly recommend doing the 100 Days of Swift first. Even though the topics are very similar, Paul Hudson does a great job of looking at problem-solving from a different perspective. He has a slightly different teaching style, and that’s exactly what you need at the beginning to understand the basics of Swift and iOS development. Repetition is king here — and that perfectly matches how the course is structured. As Paul says:

“If you want to make a success of this course, there are only two rules:

• Every day, you spend one hour reading or watching Swift tutorials, or writing Swift code.
• Every day, you post about your progress to the social media site of your choosing. Tell people!”

The one-hour-a-day part is the important one here. The lectures are built this way. And having already gone through Angela’s course (presumably), you can do more lectures per day if you’re a fast learner. On the other hand, if you need more time to grasp every single topic, the course is great for that as well.

Title: Example of an app built during 100 Days of Swift by hackingwithswift.com

What’s Next? Build a Real-world App

I believe this is the most crucial part of the learning journey. And even though I don’t have the proper statistics, I feel that this stage is where the majority of the students drop out. I am talking about the stage where you have some basic understanding and knowledge about iOS, you went through several courses and touched on multiple topics, you’re connecting puzzle pieces of knowledge and the final image starts to materialize. But you just don’t feel ready to take on a job interview yet, there are some topics that you don’t understand and you just can’t imagine yourself building a standalone real-world app by yourself. You don’t want to get back to the basics again, but the bridge from your situation to the next level seems too complex. This results in a lack of motivation and may eventually end in you giving up on iOS learning.

If you are in this phase, don’t worry. I have experienced exactly these feelings and I have a great course for you.

The course is from Sean Allan, another very well-known figure in the iOS world. The course is called iOS Dev Job Interview Practice — Take Home Project. It’s the perfect course for helping you cross over from beginner to job-interview-ready.

In the course, you will be making the GitHub Followers app. The whole process of making the app is designed to feel very similar to a real-world app or, as the name suggests, a take-home test project from a job interview. You will make the UI fully programmatically — no storyboards. Sean focuses on all the details. Correct organization of the code, avoiding code duplicates, refactoring and, in general, building the project as if you need to pass a job interview. Sean himself has worked on multiple projects for companies or his own apps and knows all the necessary practical details.

This course helped me to feel comfortable enough to take a chance, apply for a job at STRV and prepare the test project.

Title: Design for GitHub Followers app, Source: https://seanallen.co/

Go Down the Rabbit Hole

I believe that consistency in learning is a key to success. Rather than spending every other weekend, whole Saturdays staring at the screen trying to learn iOS, I recommend spending less time on studying but doing so more frequently. Are you a student or are working at a non-engineering job? Spend 1–2 hours every day studying. In the beginning, I often spent too many hours in one day, then didn’t open Xcode for a week, and I ended up not remembering anything and having to start the lesson over again.

Try to utilize tunnel vision with your goal of becoming an iOS engineer. What worked for me was to surround myself with the most approachable topics from the entire software development and Apple world.

I have some tips on how you can jump down the rabbit hole and keep yourself in tunnel vision mode. These activities are less about actively learning time and more about passively feeding yourself via the environment. It’s like when you’re trying to lose weight: It’s great to go to the gym a couple of times a week, but what can make the difference is the “passive activities” that accumulate through your day — walking instead of driving a car, biking as your form of commuting, drinking water instead of soda, etc. You know what I mean.

Here are my tips:

• Listen to the Swift by Sundell podcast, even the old episodes
• Watch Sean Allan’s Swift News
• Subscribe to Firsehip for funny yet educational content from the whole software engineering field; for example, How to Land a 100K/yr Tech Job — 10 Strategies or 10 Design Patterns Explained in 10 Minutes
• Follow Dorian Develops on his journey in software development, his ups and downs in his programming career and strategies and ideas to become a good software engineer
• Join Sean Allan’s Slack group and chat with other students or at least read their posts
• Watch older WWDC presentations by Apple
• Tweet or write a blog about your progress, even if only your partner will read it :)
• Watch SwiftUI Roadmap by Karin Prater and subscribe to her amazing channel full of great educational content
• Watch the detailed and technically-focused How to Become an iOS Developer by Paul Hudson
• Join the iOS community on Twitter

In short, surround yourself with the iOS world. Live it. Think about it. Talk about it. This will help you on your journey.

(Don’t) Get a Mentor!

In most videos and articles about how to learn software development, you will be advised to get a mentor, a senior dev in the field to help you with the learning. I can only partially agree.

All branches of software development — backend, web and mobile — are in high demand. There are not enough people for the jobs. This has one side effect and that is that everyone can become senior quite quickly, compared to other fields. This may give the senior people the confidence to mentor others, but I think that only a small amount of senior devs are suitable for the mentor role.

In fact, I think it’s so few of them that there is a high chance of being mentored by the wrong person. Is it a big deal, you ask? Might be. The wrong mentor can quickly demotivate you and can have a bad influence on you, even if the intentions are good!

If the mentor can’t adapt to your skills and learning speed, it may quickly end up with you doubting your skills and yourself. Imagine you are with a senior dev who’s explaining some advanced concept, you don’t understand his way of explaining and don’t get the topic. The mentor starts losing patience and you might start doubting yourself when, in fact, maybe the mentor chose the wrong way of explaining the topic — or maybe you were not ready for this topic at all. From my experience, the more junior the student is, the harder it is to get the right mentor.

So, as an alternative, I recommend getting in touch with other people who are learning on the same level. Talk with them about the problems you’re facing. Don’t be shy to make mistakes and ask the wrong questions. Chances are that other students might have been making the same mistake just a month ago and will give you their beginners’ perspective.

Personally, what helped me the most was talking about my journey with an iOS engineer who was also self-taught. His way of explaining stuff and presenting concepts was much more understandable for me, an equally self-taught engineer.

Don’t get me wrong, I am not saying that having a mentor is a bad thing. I think it’s an awesome thing — but to get a suitable mentor early on in your career is, from my perspective, a hard thing to accomplish. As you evolve as an engineer, it will be much easier for you, as well as for the senior-dev mentors, to talk about common topics.

Becoming iOS Engineer via the STRV Academy

I’ll sneak in a little STRV promo. Another option, yet limited by location and time and only for those who’ve passed basic iOS introduction courses, could be the STRV Academy: Becoming an iOS Engineer. After two years marked by Covid-19, STRV is back with its proven concept of an offline, hands-on academy open for applications now. And if you miss this year’s dates, stay on the lookout next year. It’s sure to be back.

Bonus: Are You a QA Engineer?

If you are working as a QA engineer, analyst or tester and you’d like to transition to iOS development, this part is for you. I can help here as well — because that’s exactly my story.

A couple of years back, I was working as a QA Tester. There was a task that nobody on the project wanted to push forward: test automation on iOS and Android. I decided I will try to pursue this mission myself. I chose to start with iOS because my cooperation with the iOS engineers in the team was pleasant.

I didn’t know much about it because, in my previous job, I was writing automated tests in Java purely for API. Mobile test automation was very new to me. At first, I had to decide whether to use Appium, which could run tests for both iOS and Android, or to go the native route. Luckily, the resources I got into made me go the native way. If you’d like, read more about Why Use Native UI Test Automation for Mobile Apps.

This goal of mine, to create UI automated tests for our iOS app, brought me to this course — which is nothing in comparison to the other courses I’ve recommended, but it’s what I started with. And it sent me in a good direction. What followed was a lot of Googling, try-fail situations and, finally, writing some tests in Swift for XCUITest. In the end, none of them were used in the production CI. But it laid my Swift foundation and helped me to get on the track of iOS development.

You Can Do It!

Good luck on your iOS journey. Get in touch in case of any questions or concerns, I will be more than happy to discuss any topic.

And to end with, I’d like to thank Gleb, Honza, Filip, Ondra, Dan and everyone who has helped (and is still helping) me on my journey.

PROJECT 25 — Selfie Share

MILESTONE PROJECT 8 (projects 22–24)

• Milestone project 8 was a bit different, the goal was not to create a new app from scratch but only to implement 3 swift extensions

Challenge:

1. Extend UIView so that it has a bounceOut(duration:) method that uses animation to scale its size down to 0.0001 over a specified number of seconds. ✅
2. Extend Int with a times() method that runs a closure as many times as the number is high. For example, 5.times { print("Hello!") } will print “Hello” five times. ✅
3. Extend Array so that it has a mutating remove(item:) method. If the item exists more than once, it should remove only the first instance it finds. Tip: you will need to add the Comparable constraint to make this work! ✅

PROJECT 24 — Teqchnique project — Strings

Day 81–81, 27th of May

I learned about:

• Create String Extension in order to create custom properties and methods of the String struct for example extension allowing to access i-th character in the string like you would with array : string[i]
• more practice with String methods like: hasSuffix(), hasPrefix(), contains(where:), dropFirst(), uppercased(), capitalized(),etc
• Formating strings with NSAttributedString, example:

• There is also a chance to format just specific parts of the string

Challenge:

1. Create a String extension that adds a withPrefix() method. If the string already contains the prefix it should return itself; if it doesn’t contain the prefix, it should return itself with the prefix added. For example: "pet".withPrefix("car") should return “carpet”. ✅
2. Create a String extension that adds an isNumeric property that returns true if the string holds any sort of number. Tip: creating a Double from a String is a failable initializer. ✅
3. Create a String extension that adds a lines property that returns an array of all the lines in a string. So, “this\nis\na\ntest” should return an array with four elements.

PROJECT 23 — Swift Ninja

Day 77–80, 26th of May

I decided to skip this SpriteKit project because I am not expecting to use SpriteKit in the future.

PROJECT 22 — Detect-a-Beacon

Day 74–76, 25th of May

I learned about:

• Requesting location
• CoreLocation framework
• CLLocationManager

Description:

Simple app showing distance to random iBeacon which is measured by Apple beacon technology using Bluetooth.

Today I learned about:

• Core Location
• CLBeaconRegion
• What is iBeacon
• Asking the user for permission about location — All the time (even when the app is not running ) or when the app is active.
• Using location when the app isn’t running is of course highly sensitive information, so Apple flags it up in four ways:

1. If you request Always access, users will still get the chance to choose When In Use.
2. If they choose Always, iOS will automatically ask them again after a few days to confirm they still want to grant Always access.
3. When your app is using location data in the background the iOS UI will update to reflect that — users will know it’s happening.
4. Users can, at any point, go into the settings app and change from Always down to When In Use.

MILESTONE PROJECT 7 (projects 19–21)

Day 73, 23rd of May

PROJECT 21 — technique project — local notifications

Description:

Another technique project, this time focused on notifications. There are two types of notifications local and push. They are not the same. Local notification can be scheduled only in the app but the push notifications require a dedicated server (or service, if you outsource) to send from.

I learned about:

• You can’t post messages to the user’s lock screen unless you have their permission so in order to send local notifications in our app, we first need to request permission
• How to register and schedule a local notification
• Request permission: In the requestPermision() of UNUserNotificationCenter we have to specify what kind of notification we want to request for, for example options: [.alert, .badge, .sound]
• Schedule Notification: in order to schedule local notification we need to configure 3 things: content (what to show), a trigger (when to show it), and a request (the combination of content and trigger.)
• Notification trigger, when to show the notification — can be a calendar trigger that shows the notification at an exact time, it can be an interval trigger that shows the notification after a certain time interval has lapsed, or it can be a geofence that shows the notification based on the user’s location.

• Content of the notification: UNMutableNotificationContent has lots of properties that customize the way the alert looks and works
• To attach custom data to the notification, e.g. an internal ID, use the userInfo dictionary property (in the content)
• You can also attach custom actions by specifying the categoryIdentifier property (also in the content of the notification)
• new data type called DateComponents

Challenge:

1. Update the code in didReceive so that it shows different instances of UIAlertController depending on which action identifier was passed in.
2. For a harder challenge, add a second UNNotificationAction to the alarm category of project 21. Give it the title “Remind me later”, and make it call scheduleLocal() so that the same alert is shown in 24 hours. (For the purpose of these challenges, a time interval notification with 86400 seconds is good enough – that’s roughly how many seconds there are in a day, excluding summer time changes and leap seconds.)
3. And for an even harder challenge, update project 2 so that it reminds players to come back and play every day. This means scheduling a week of notifications ahead of time, each of which launch the app. When the app is finally launched, make sure you call removeAllPendingNotificationRequests() to clear any un-shown alerts, then make new alerts for future days.

PROJECT 20 — Fireworks game

Days 70–72, 18th of May

Description:

Another SpriteKit project. This time a little firework game where the goal is to tap rockets of the same colour and make them explode by shaking of the tablet.

I learned about:

• UIBezierPath
• New SKAction follow(), which takes in CGPath as a parameter and makes the node move along that path.
• new syntax for case let — in the case of this project it is used to loop over an array of SKNode but because we need to execute some code only when the node is SKSpriteNode. We create a new constant with let and typecast it to SKSpiriteNode

Challenge:

1. For an easy challenge try adding a score label that updates as the player’s score changes. ✅
2. Make the game end after a certain number of launches. You will need to use the invalidate() method of Timer to stop it from repeating. ✅
3. Use the waitForDuration and removeFromParent actions in a sequence to make sure explosion particle emitters are removed from the game scene when they are finished.

PROJECT 19 — Safari extension — JavaScript Injection

Days 67–69, 17th of May

Description:

The goal of this project is not an application or game as before but rather a Safari extension. This extension allows running JavaScript code that we provide to the text TextView. So for example we can enter and display an alert with the title of the page that we previously fetched from the Safari itself. Also, we have fixed a keyboard issue, where text inputted into TextView was hiding under the keyboard if it was too long. It was fixed with Pauls own method — observing values from NotificationCenter. In the observer, we react to any change by adjusting the contentInset and scrollIndicatorInsets of our text view.

I learned about:

• When our Swift extension finishes we can send values back to JavaScript. Anything we send back is then made available to our action file.
• The addObserver() method of NotificationCenter lets us watch for a particular notification. This lets us attach some code to run when a notification comes in.
• Scroll indicator insets control how big the scroll bars are relative to their view.
• You must ship an app if you want to ship an extension. Extensions are shipped inside the parent app.
• The contentInset property of a UITextView determines how text is placed inside the view.
• We usually rely on the capture list from the outer closure.

Challenge

1. Add a bar button item that lets users select from a handful of prewritten example scripts, shown using a UIAlertController – at the very least your list should include the example we used in this project. ✅
2. You’re already receiving the URL of the site the user is on, so use UserDefaults to save the user's JavaScript for each site. You should convert the URL to a URL object in order to use its host property.
3. For something bigger, let users name their scripts, then select one to load using a UITableView.

PROJECT 18 — technique project — debugging

Days 65–67, 11th of May

Description:

• Another technique project. Project with no real app as an outcome Only allows to practices some technique in the playground.
• This time — debugging

I learned about:

• different approaches to debugging
• print() — the lamest approach to debugging. Used with Swift’s string interpolation to see the contents of your variables when your app is running.
• assert() — lets us ensure the app’s state is exactly what you thought it was, for example, assert(array.isEmpty)
• breakpoints — allows us to stop the program on the line, where the breakpoint is placed when the program execution comes to that line. It then allows to see the current values of all variables.
• conditional breakpoints — create a condition for when breakpoint should be applied, for example, every 10th iteration of the loop
• exceptions breakpoints — can be automatically triggered when an exception is thrown
• backtrace —way how to track functions and from where they were called. So if a bug is found somewhere in the method d(), this back trace will show you that d() was called by c(), which was called by b(), which in turn was called by a() – it effectively shows you the events leading up to the problem, which is invaluable when trying to spot bugs.
• view debugging — Capture View Hierarchy, great function of xCode. This debug mode is perfect for times when you know you’ve placed your view but for some reason can’t see it.

Challenges:

1. Temporarily try adding an exception breakpoint to project 1, then changing the call to instantiateViewController() so that it uses the storyboard identifier “Bad” – this will fail, but your exception breakpoint should catch it. ✅
2. In project 1, add a call to assert() in the viewDidLoad() method of DetailViewController.swift, checking that selectedImage always has a value. ✅
3. Go back to project 5, and try adding a conditional breakpoint to the start of the submit() method that pauses only if the user submits a word with six or more letters. ✅

PROJECT 17 — Space Race

Days 64–65, 10th of May

Description:

Another mini-game. This time small rocket flying thru space and trying to avoid collision with randomly generated objects.

I learned about:

• How to use Timer to trigger a repeating method every few seconds
• Postpone the initial state of the particles animation so it looks good right from the start (used for moving stars) with advanceSimulationTime()
• linearDamping and angularDamping properties of SKPhysicsBody to force sprites to retain their speed and spin, rather than slowing down over time (enemy objects)

Challenges:

1. Stop the player from cheating by lifting their finger and tapping elsewhere — try implementing touchesEnded() to make it work.
2. Make the timer start at one second, but then after 20 enemies have been made subtract 0.1 seconds from it so it’s triggered every 0.9 seconds. After making 20 more, subtract another 0.1, and so on. Note: you should call invalidate() on gameTimer before giving it a new value, otherwise you end up with multiple timers.
3. Stop creating space debris after the player has died.

PROJECT 16 — MapKit

Days 60–63, 7th of May

Description:

Simple one screen app displaying a map with pins representing “interesting” places. Every pin has its name and link to Wikipedia which is displayed as webView inside of the app on the next screen.

I learned about:

• MKMapView
• MKAnnotation
• MKPinAnnotationView
• CLLocationCoordinate2D
• Different MapView.mapType , for example, .satellite

Challenges:

1. Try typecasting the return value from dequeueReusableAnnotationView() so that it's an MKPinAnnotationView. Once that’s done, change the pinTintColor property to your favourite UIColor. ✅
2. Add a UIAlertController that lets users specify how they want to view the map. There's a mapType property that draws the maps in different ways. For example, .satellite gives a satellite view of the terrain. ✅
3. Modify the callout button so that pressing it shows a new view controller with a web view, taking users to the Wikipedia entry for that city. ✅

MILESTONE PROJECT 6 (projects 13–15)

Day 59, 6th of May

Challenge:

Your challenge is to make an app that contains facts about countries: show a list of country names in a table view, then when one is tapped bring in a new screen that contains its capital city, size, population, currency, and any other facts that interest you.

My approach:

• getting data from open API https://restcountries.eu/
• created one central class APIManager which is calling this API with customized calls
• fetching all countries and displaying them in the initial tableView
• then I fetch single country data based on what cell was tapped and display info on the new screen
• so far not able to fetch flag picture

PROJECT 15 — technique project — Animations

Days 57–58, 4nd of May

Description:

• Another technique project.
• Project with no real app as an outcome
• Only allows to practices some technique in the playground.
• This time — Animations.

I learned about:

• UIView.Animate()
• How to use Alpha to make object invisible
• How to move, rotate, and scale views using CGAffineTransform.
• Scale — CGAffineTransform(scaleX: 2, y: 2)
• Move — CGAffineTransform(translationX: -256, y: -256)
• Rotate — CGAffineTransform(rotationAngle: CGFloat.pi)
• Make invisible — self.imageView.alpha = 0
• Return to original appearence —self.imageView.transform = .identity

Challenges

1. Go back to project 8 and make the letter group buttons fade out when they are tapped. We were using the isHidden property, but you'll need to switch to alpha because isHidden is either true or false, it has no animatable values between. ✅
2. Go back to project 13 and make the image view fade in when a new picture is chosen. To make this work, set the alpha to 0 first. ✅
3. Go back to project 2 and make the flags scale down with a little bounce when pressed. ❌

PROJECT 14 — Whack-A-Pinguine

Days 54–56, 2nd of May

https://github.com/lukassmetana/project14

Description:

• Simple Whack-a-mole type game. Instead of moles, there are good and bad pinguins.

I learned about:

• SKTexture — Changing sprite images without moving the sprite, using SKTexture
• SKCRopNode — Cropping a sprite so that only part of it is visible, using SKCropNode
• More SKActions, including moveBy(x:y:), wait(forDuration:), sequence(), and even how to run custom closures using run(block:)
• The asyncAfter() method of GCD, which causes code to be run after a delay — used for delaying start of the round

Challanges:

1. Record your own voice saying “Game over!” and have it play when the game ends. ✅
2. When showing “Game Over” add an SKLabelNode showing their final score. ✅
3. Use SKEmitterNode to create a smoke-like effect when penguins are hit, and a separate mud-like effect when they go into or come out of a hole. ✅ (only effect when they are hit)

PROJECT 13 — PhotoFilters

Days 51–53, 29th of April

https://github.com/lukassmetana/project13

Description:

• App that allows you to apply a filter on pictures from your photo library and save them

I learned about:

• UISlider — How to let the user select from a range of values using UISlider
• Using Core Image (CIContext and CIFilter) — Create Core Image contexts using CIContext, and creating then applying Core Image filters using CIFilter.
• UIImageWriteToSavedPhotosAlbum() — Saving images back to the user’s photo library by calling the UIImageWriteToSavedPhotosAlbum() function
• More practice using UIImagePickerController, to select pictures from the user’s photo library.

Challenges:

1. Try making the Save button show an error if there was no image in the image view. ✅
2. Make the Change Filter button change its title to show the name of the currently selected filter. ✅
3. Experiment with having more than one slider, to control each of the input keys you care about. For example, you might have one for radius and one for intensity. ❌

MILESTONE PROJECT 5 (projects 10–12)

Day 50

Challenge:

• Your challenge is to put two different projects into one: I’d like you to let users take photos of things that interest them, add captions to them, then show those photos in a table view. Tapping the caption should show the picture in a new view controller

PROJECT 12 — technique project — UserDefaults

Days 48–49

PROJECT 11 — Pachinko

Days 45–47, 21st of April

https://github.com/lukassmetana/project11

Description:

• First game-project using SpriteKit — Apple’s high-performance 2D games framework.
• I would not even call it a game because there is no clear goal. User can just drop balls and if they end up in the green slot score increases and if they end up in the red one, score decreases.
• Also, it's possible to add obstacles. When the ball hits an obstacle they are both “destroyed” and disappear.

I learned about:

• A lot of stuff from SpriteKite 😀.
• The SKSpriteNode class is responsible for loading and drawing images on the screen.
• Draw sprites using a selection of blend modes. We used .replace for drawing the background image, which causes SpriteKit to ignore transparency. This is faster, and perfect for our solid background image.
• Add physics to sprite nodes using SKPhysicsBody, which has rectangleOf and circleWithRadius initializers that create different shapes of physics bodies.
• Adding actions to things, such as spinning around or removing from the game, is done using SKAction.
• Measure angles in radians using CGFloat.
• Detecting user interaction with the screen (game) with touchesBegan(_:with:)

Project 10 — Names to Faces

Days 42–44, 17th April

https://github.com/lukassmetana/project10

I learned about:

• UICollectionView
• Designed a custom UICollectionViewCell, first in the storyboard and then in code. No like with UITableViewCell, CollectionViewCell always must be customized.
• UUID — easy way how to create unique identifiers, which is the easiest way to generate filenames that are guaranteed to be unique
• Saving Data to disk — converting each UIImage to a Data that could be written to disk, using jpegData()
• appendingPathComponent() method, as well as Paul Hudson'sgetDocumentsDirectory() helper method. Combined, these two let create filenames that are saved to the user’s documents directory.

The thing I should have probably already known but realized just now:

• UiCollectionView

Review quiz score: 11/12

Challenges:

1. ✅
2. ✅

MILESTONE PROJECT 4 (projects 7–9)

Day 41

Challenge:

• The challenge is this: make a hangman game using UIKit.

PROJECT 9 — technique project — Grand Centra Dispatch

Days 39–40, 11th of April

https://github.com/lukassmetana/project9

Review quiz score: 11/12

Challenges:

PROJECT 8 — Swifty Words

Days 36–38, 8th — 10th of April

https://github.com/lukassmetana/project8

I learned about:

• Building UI programmatically
• Content hugging and content compression resistance priority
• Property observer: didSet
• Working with strings: contentsOf, components(separatedBy: ), enumerated(), replacingOccurrences()
• Add action to UIButton with addTarget()
• Difference between shuffle() and shuffled() array

The thing I should have probably already known but realized just now:

• UIView is a parent class of all UIKit’s types like UIButton, UILabel, etc.

The thing I should probably remember: nil

Review quiz score: 11/12

Challenges:

1. ✅
2. ✅
3. ✅

PROJECT 7 — Petitions

Days 33–35

https://github.com/lukassmetana/project7

I learned about:

• UITabBarController
• Getting data from the internet with Codable protocol
• Data data type
• Create custom HTML inside of WebView

The thing I should have probably already known but realized just now: nil

The thing I should probably remember: nil

Review quiz score: 11/12

Challenges:

1. ✅
2. ✅
3. ✅

MILESTONE PROJECT 3 (projects 4–6)

Day 32

Challenge:

• This time your job is to create an app that lets people create a shopping list by adding items to a table view.

PROJECT 6 — technique project — Auto Layout

Days 30–31

PROJECT 5 — World Scramble

Days 27 — 29

I learned about:

• weak, strong, unowned references

PROJECT 4 — Easy browser

Days 24–26

I learned about:

• WKWebView
• UIAlertController action sheets
• UIToolbar, toolBarItems, rightBarButtonItem
• UIProgressView

MILESTONE PROJECT 2 (projects 1–3)

Day 23

Challenge:

Your challenge is to create an app that lists various world flags in a table view. When one of them is tapped, slide in a detail view controller that contains an image view, showing the same flag full size. On the detail view controller, add an action button that lets the user share the flag picture and country name using UIActivityViewController.

PROJECT 3 — technique project — UIActivityViewController

Day 22

I learned about:

• UIBarButtonItem
• UIActivityViewController

PROJECT 2 — Guess the flag

Days 19–21

I learned about:

• UIButton
• Assets — iOS assets come in three sizes — 1x , 2x , 3x, if you’re supporting only iOS 10 or later devices you only need to include the @2x and @3x images
• CALayer (CA = Core Animation)— every iOS view is backed by CALayer, which is a Core Animation data type responsible for managing the way views looks. Conceptually, CALayer sits beneath all UIViews (that's the parent of UIButton, UITableView, and so on), so it's like an exposed underbelly giving lots of options for modifying the appearance of views, as long as you don't mind dealing with a little more complexity. Example of CALayer property for UIButton isborderWidth.
• CGColor is is type by which we can set colour to borderColor of our layer. (CG = CoreGraphics)
• UIAlertController

Challenges:

1. Try showing the player’s score in the navigation bar, alongside the flag to guess.
2. Keep track of how many questions have been asked, and show one final alert controller after they have answered 10. This should show their final score.
3. When someone chooses the wrong flag, tell them their mistake in your alert message — something like “Wrong! That’s the flag of France,” for example.

PROJECT 1 — Storm Viewer

Days 15–18

https://github.com/lukassmetana/project1

Description:

• Very simple TableView app displaying pre-loaded pictures (part of the repository), counting the number of views of every picture.
• Added as part of a challenge from different weak: the number of views is saved in UserDefaults.

I learned about:

• UITableView
• UIImageView
• FileManager
• Outlets
• StoryBoard
• AutoLayout
• UIImage
• instantiateViewController from Storyboard
• pushViewController with navigationController

—