My Journey at the Apple Developer Academy

**Jan 2023** (This article is also available in [[Apple Developer Academy 회고|Korean]]) ### An Academy Centered on Autonomy If you’re used to environments where tasks and assignments are given based on a fixed curriculum, the Academy’s approach might feel unfamiliar. Here, you’re given a one-year project period and a simple set of guidelines—everything else is self-directed. You learn iOS development and its ecosystem by discovering what you want to do, discussing ideas with fellow learners, and asking mentors for advice. At first, I kept wondering, **“Is it really okay to have this much freedom?”** So every day, I’d ask the mentors: _“What should I do next?”_ _“Is it okay to do it this way?”_ —trying to find the right answer. But during the second project, I realized: **“Oh, there is no right answer.”** From then on, I teamed up with people who shared similar interests and tried out various ideas together. Even when we failed, there was always something to learn, and the process itself was valuable. This way was fine. That way was fine too. ![[신난다.png|center|w25]] ### MC1: My First SwiftUI In the first project, I met someone who became a huge influence—thanks to them, I learned so much, from Git management to iOS development. This might sound obvious, but here’s a solid tip: if there’s someone known as a “pro” in the Academy, try teaming up with them at least once. You’ll learn a ton just by being around them. Seriously, it’s the best. Our first project was an app built under the motto **“Recycle with a single touch”**, designed to quickly provide recycling information and guide users on how to sort waste based on their local regulations. We named it **Sugeo-ttakdae**. ![[분리수거딱대.png]] The app was built using **SwiftUI**, **Vision**, **AVFoundation**, and public datasets. When users scanned a barcode, the app provided instructions on how to recycle the item. We also added light gamification elements, allowing users to level up or unlock characters based on how actively they practiced recycling. Additionally, we included a feature to check recycling pickup schedules, which vary by region. This project was my first time using **SwiftUI**. I had only worked with **UIKit** before, so I was impressed by how much more intuitive layout building felt with SwiftUI. It was especially convenient to see UI updates instantly while writing code. With UIKit, you have to manage layout constraints manually—either through storyboards or programmatically—but SwiftUI’s declarative syntax made screen composition more straightforward. That said, I was so used to UIKit that adjusting to SwiftUI’s data flow and custom UI approaches took some time. Still, I found it to be a very appealing framework, with its readable code and easier maintenance. Through this project, I was able to directly experience both the strengths and limitations of SwiftUI, and it made me want to explore it more deeply. ![[UIKit은 가라.png|w60|center]] ### NC1: A Study Culture That Formed Naturally During the NC1 phase, we worked on individual projects. At the time, I was particularly interested in UI/UX, so I decided to build a platform app that focused on enhancing user experience. Even though I’m a developer, I believe **good UI/UX is something that PM, developers, and designers should think about together**. With that in mind, I started an **HIG study group** with fellow learners who shared the same interest. Around this time, over 20 clubs had naturally formed—electronic music, English conversation, badminton, and more. Nobody said, “You have to start a club.” But everyone just started forming and joining groups on their own. It was fascinating to watch. Our HIG study group turned out to be a success, and we wrapped everything up within two months. Since the group included people from different domains—like designers and developers—we exchanged a lot of helpful insights, from design considerations to development tips. Rather than just reading and summarizing documents, we went further by analyzing real-world app examples to understand the HIG guidelines more deeply. ![[HIG 스터디.png]] <div style="text-align:center">Some parts of the official HIG documentation lacked examples or were hard to follow, so we tried to fill the gaps by studying actual app cases together.</div> But as if by some twist of fate, **the official HIG documentation got a complete overhaul.** In the end, it took us another three months to update everything. Well, that’s life. Ha. ![[거짓말.png|center|w35]] ![[HIG 노션.png|center|w80]] ### MC2: My First Encounter with a Startup Partner The project I worked on during MC2 was called **PacKit**— a **desk organizer app** designed for hot desk users, freelancers, or anyone whose work environment changes frequently. The main goal was to offer **widget-style features** that would help users quickly set up their workspace anytime, anywhere. We explored ways to combine a kanban board, schedule management, to-do lists, and project tracking into **interactive widgets displayed on a single screen**. At the time, iPad widgets didn’t support interactivity, so we thought implementing these features would give us a competitive edge. We also believed that **supporting cross-device sync** would make the app even more useful for productivity. In addition, we ran into limitations with the way iPad widgets were positioned. By default, iPad stacked widgets from the top, pushing existing ones downward. With PacKit, we implemented a system that allowed users to freely arrange widgets wherever they wanted on the screen. However, as we added more features, the app’s scope grew far bigger than expected. In the end, we had to wrap up the project without completing every function. (The biggest challenge was that each widget essentially needed to act like a standalone app.) Still, from planning to development, the entire process was a genuinely engaging experience. ![[왕따봉.png|center|w30]] There were two moments from this project that really stood out to me. The first was the **actual user testing** process. The project started from a simple idea — “It’d be nice if an app like this existed,” but we felt it was important to reflect real users’ needs and pain points, so we decided to conduct **user testing**. Before developing the app, we **printed out a prototype** and had users simulate using it, so we could collect feedback as if they were interacting with a real app. This process brought up all kinds of feedback we hadn’t expected. For instance, some users didn’t intuitively understand the purpose of certain menus, and a few features were perceived differently than we had intended. Thanks to that, we had a chance to **revise the UI/UX and create a more intuitive flow** before jumping into development. ![[사용자 테스트.jpg|center|w45]] <div style="text-align:center">Raw and unfiltered</div> The second memorable moment was when one of my teammates and I spent several days **figuring out how to replicate natural animations and layouts similar to iPad widgets**. We looked into Apple’s **PIP animation** and other resources, discussing non-stop how we could make the widgets move and behave more smoothly. We ended up in long, late-night discussions, and the process of building together was genuinely fun. Collaborating with someone who shares your interests and exchanging ideas deep into the night—it felt like a rare and lucky experience. Maybe that’s why the bond with the teammates I met in MC2 went beyond just this one project— **we continued on to the final project together, and even explored startup ideas as a team.** | ![[레이아웃 고민 1.jpg]] | ![[레이아웃 고민 2.jpg]] | ![[레이아웃 고민 3.jpg]] | | :----------------: | :----------------: | ------------------ | <div style="text-align:center">Traces of all that effort</div> ![[레이아웃 영상.mov]] ### NC2: Pull-Up Counting App At the time, I was really into doing pull-ups. I had just set up a chin-up and dip station at home, and while practicing, I thought it’d be fun to make an app that could **automatically count pull-up reps**. It also seemed like a good opportunity to experiment with **Core ML**, so the idea naturally turned into a project. | ![[턱걸이앱 1.png]] | ![[턱걸이앱 2.png]] | ![[턱걸이앱 3.png]] | | --------------- | -------------- | -------------------------- | To test the app, I used not only footage of myself, but also various pull-up videos from YouTube. The accuracy was better than expected—it was able to recognize most forms pretty well. That said, one thing I wish I had done was adding a feature to **give a warning sound when the form was incorrect**, but in the end, it stopped at just a basic counting function. If I get the time, I’d love to take it further and actually use it for real pull-up training. ![[강한 키티.png|center|w25]] ### MC3: 🌙 Maximum Efficiency with Minimum Sleep 🌞 I’d often heard that adjusting your sleep in 90-minute cycles helps you wake up feeling refreshed. Personally, I tend to sleep around 6 hours or 7 hours and 30 minutes, but having to calculate the time manually every time to set my alarm was quite a hassle. There’s a fair amount of research backing the idea that sleep cycles repeat every 90 minutes. Below is one of the sleep time calculator sites I used frequently. https://thesleepcharity.org.uk/information-support/adults/sleep-calculator/ To solve that inconvenience, I planned and developed an **alarm app based on 90-minute sleep cycles** for this project. The main features were: - Set alarms **every 90 minutes** from the current time for waking up or going to sleep - Calculate bedtime **backward from a desired wake-up time** (e.g. 7:00 AM) - **Record sleep history** and provide a simple **sleep quality assessment** ![[Sleepie.png]] In the previous MC2 project, I spent too much time on design, so this time I kept the interface as close as possible to the default iPhone app design, focusing more on development. Thanks to that, I was able to release it on the App Store within the deadline. This was my first time directly handling App Store distribution, and although Apple’s review process felt a bit strict at first, going through it helped me understand the full release workflow—which was the biggest takeaway for me. When I finally downloaded the app myself after it was released, everything I’d worked on felt real. Up until then, most of the apps I built were only used internally, so distributing an app that users could actually download gave me a different sense of achievement. In this project, I also focused on using **PRs (pull requests) and code reviews actively**. This helped me go beyond just building features, and really think about **better implementation strategies and maintaining consistent code style**. Through the code reviews, I was able to **catch potential issues early on** and **explore more efficient ways to write code**. That said, there was one challenge: **the size of each PR became too large.** With so many file changes, it naturally became burdensome for reviewers to go through. So I made a mental note for the next project — **to keep each PR under 200 lines whenever possible.** ![[귀여운 커밋 목록.png|center|w85]] <div style="text-align:center">cute emoji commit convention</div> ![[코드리뷰.png|center|w85]] <div style="text-align:center">I still remember how nervous I was during my first code review.</div> ### Macro **Currently organizing the rest…** 📝 ![[기능정의서.png]]