How I Built My First iOS App with UIKit at Age 15

At 15, I had more curiosity than experience. I knew a little Swift, had watched parts of Apple’s developer videos, and could make a simple command-line program, but an iPhone app felt like a much bigger project. UIKit looked especially serious because it involved view controllers, storyboards, Auto Layout, navigation, and several files working together.

I built my first app on a Mac in Atyrau, Kazakhstan, while learning after school. The project was small: a basic daily planner that let users add tasks, mark them as complete, and remove them. It was not ready for the App Store, yet it taught me how an actual iOS project is structured and how much patience interface development requires.

For a student in Australia, the same starting point might happen after school in Melbourne, during a rainy afternoon in Hobart, or between cricket training and homework in Brisbane. The tools are the same everywhere, but the best way to learn is to build something small enough to finish and useful enough to care about.

Choosing UIKit For A First Project

I chose UIKit because it was widely used in existing iOS apps and had a large amount of learning material. SwiftUI was already attracting attention, but UIKit helped me understand ideas that still matter: views, controllers, user input, constraints, and the app lifecycle. I wanted to know what was happening rather than simply copy a modern template.

My first feature list was deliberately short. The app needed a table view for tasks, a button to add a task, a screen for entering text, and a way to delete an item. I wrote these requirements in a notebook before opening Xcode. That simple step stopped me from adding accounts, cloud syncing, reminders, themes, and other features that would have made the first version impossible to manage.

The project name was “DayList”. I created it as a UIKit App in Xcode, selected Swift, and used a simple storyboard-based interface. I kept the deployment target reasonably current so I could test on a real iPhone without worrying about older system versions. For a young developer, reducing setup decisions leaves more energy for learning.

Building The Screen In Xcode

The first screen used a UITableViewController. I started with a local array of strings and displayed each task in a standard cell. The code was not complicated, but I had to understand the table view data source methods: how many rows existed, what each cell should show, and how the array changed when a task was deleted.

Adding a task taught me about navigation. I created a second view controller with a text field and a save button. A navigation controller connected the two screens, while a delegate passed the typed text back to the first screen. At first, I tried to make every object responsible for everything. That produced confusing code, so I learned to give each controller a clearer job.

I spent a surprising amount of time on Auto Layout. A screen that looked fine in the storyboard could behave badly on a smaller iPhone or in landscape mode. I added constraints for leading and trailing margins, button height, and vertical spacing. Testing on different simulator sizes showed why responsive layout matters, whether the app is used on a Sydney train or at a desk in Perth.

When I wanted a visual break from debugging, I looked at simple interface examples and design references, including mobile design ideas. I was not trying to copy another product. I was learning how spacing, contrast, and short labels make an app feel easier to use.

The Bugs That Taught Me The Most

My first serious bug appeared when I saved a blank task. The table view added an empty row, which made the app look broken. I fixed it by trimming whitespace and checking that the resulting string was not empty before updating the data source. It was a small validation rule, but it showed me that users do not interact with an app as neatly as a developer expects.

Another problem came from table view updates. I changed the array and called reloadData(), which worked, but I did not understand why. Later, I learned about inserting and deleting rows with beginUpdates() and deleteRows(at:with:). For the first version, reloading was acceptable. Learning when a simple solution is enough is part of becoming a better developer.

The simulator also hid a mistake because the keyboard covered my text field. On a real phone, the problem was obvious. I adjusted the layout and tested keyboard behaviour more carefully. Australian users might be checking a task list in a busy café in Adelaide or standing near a tram stop in Melbourne, so an app should remain usable in imperfect conditions.

I kept a bug list in plain language: “empty task allowed”, “keyboard covers button”, “delete crashes after reopening”, and “long text looks strange”. Writing symptoms before solutions made debugging less emotional. It also gave me a record of progress when I felt that the app was moving too slowly.

Learning From Other Developers

I did not learn everything from one course. I used Apple documentation, Swift experiments, developer videos, and questions from programming communities. Documentation was difficult at first because it often explained an API without showing the full context. I began reading the examples, then creating tiny test projects instead of pasting code directly into DayList.

A local developer community helped me see that my problems were normal. I found beginner-friendly material and discussions through iOS development resources, which made the path feel less isolated. Seeing other developers discuss UIKit, Swift, and Xcode encouraged me to share progress instead of waiting until the app looked perfect.

I also learned to be careful with advice from short videos. A code snippet can solve one issue while creating another, especially when it uses an outdated API or skips explanation. Before keeping a solution, I tried to describe it in my own words and rebuild it from an empty file. If I could not explain it, I did not truly understand it.

The Australian app market gave me another useful perspective. A small student project does not need to compete with polished products from Sydney startups or large international companies. It needs a clear purpose, readable design, and reliable behaviour. Local users may care about transport, school activities, sporting clubs, weather, or regional services, which can inspire practical project ideas.

What I Would Do Differently Now

My first app stored tasks only in memory, so all data disappeared when the app closed. That was fine for learning UIKit, but a real planner needs persistence. In the next version, I would use UserDefaults for simple settings or Core Data for a more structured model. I would also separate the task model from the view controller earlier.

I would test accessibility from the beginning. Larger Dynamic Type sizes, VoiceOver labels, sufficient colour contrast, and buttons with comfortable touch targets should not be last-minute fixes. A school project can still be welcoming to users with different needs, and accessibility knowledge is valuable for anyone hoping to work in the Australian technology industry.

I would also create a Git repository on the first day. At 15, I treated version control as something professionals used, but it would have helped me recover from mistakes and show my progress. A clear README with screenshots, features, and known limitations would make the project more useful in a junior portfolio or a future application for a student programme.

The comparison below summarises the choices I made and the upgrades I would plan for a stronger second version.

Area	First version	Better next version
Interface	Storyboard and standard UIKit controls	Reusable custom views with clearer layout constraints
Storage	Temporary in-memory array	UserDefaults or Core Data
Navigation	Navigation controller and delegate	Clear coordinator or navigation pattern
Testing	Manual checks in the simulator	Device testing, unit tests, and accessibility checks
Design	Basic task list	Empty states, Dynamic Type, and polished visual hierarchy
Portfolio value	Working experiment	GitHub repository, README, screenshots, and demo video

Finishing that first app changed how I viewed programming. I stopped thinking that experienced developers simply knew the right answer immediately. They read documentation, test assumptions, inspect errors, and improve one small part at a time. UIKit was challenging, but every screen and bug gave me a more useful mental model.

My next concrete step is to rebuild DayList with persistent storage, commit the work to GitHub, and test it on a physical iPhone before adding any new feature.