Danielle
Hello, everyone. Thank you so much. Good morning.
So my name is Danielle, and I started learning Swift and SwiftUI in June of 2023. So I knew that I wanted to try out software development, but I was really overwhelmed by the number of options and specialties that were out there available. Seeing WWDC23 and the Vision Pro announcement made me realize instantly that I wanted to build products for that platform.
So my path was forged and made everything click for me. I found Paul Hudson's Hacking with Swift and 100 Days of SwiftUI after just a few short days of research about my options. On June 19, 2023, I declared my very first Swift variable.
Since then, I've published eight apps to the iOS and VisionOS app stores. So is there anybody here today who's looking to get an app published soon? Awesome.
Would you like to get that app published by the end of the year? Yeah. So I have five tips for you to help you get started.
All right. So tip number one, your apps don't have to be large or complicated. So like many of you, in December of 2023, I wrote out my goals for the new year.
One of those goals was to get an app in the app store. In my head, this was a super hard thing to do. I had looked at the successful apps in the app store and the apps of the indie devs I found successful, and I didn't know how I was going to get an app that would look that good published.
It wasn't until I saw Kyle Lee's episode of Code Newbie, my favorite podcast, where he spoke about his first two apps. His first one was just a notepad and his second one was a text field that allowed you to write large text. It was then that I realized that your app didn't have to be grand.
It completely shattered my preconceived notions about what a published app had to be. So I began this journey wanting to build apps for VisionOS, so I started thinking about what kind of app I could make for that platform. Being a long-time Apple fan, I knew that first-generation products tend to be lacking certain basic utilities or necessities that users may find helpful or useful.
So I thought a timer would be, one, useful, and, two, missing as a first-party feature from the platform at launch. So I began building this timer at about 9 a.m. By 3 p.m. the same day I had it submitted to App Store Review. I went on YouTube to figure out how to build the logic of the timer and most of that time was spent trying to figure out screenshots, privacy policy, support page, and all of the necessities for your App Store submission.
On January 17th of 2024, I got the notification that my first app had been accepted into the App Store. It's hard to explain what getting that first app accepted felt like. I had only been learning Swift for six months at this point, and I didn't not feel in any way experienced enough to be able to call myself a published developer.
I began this journey with the goal of publishing apps for VisionOS, and six months later, there was a VisionOS App Store listing with my name under developer. So the cat was out of the bag. I knew how easy publishing an app could be, and I was determined not to stop there.
By the time the Vision Pro released, I had three utility apps on the App Store with one more coming just a week later. They were all built in one day or less. They were all MVPs, and they all look different now than they did when they first released.
So tip number two, build apps that you're passionate about, and building apps that you're passionate about helps with the difficulties of the development process. So the first app I ever built on my own was to solve a problem at my job. I worked in medical cannabis dispensary management, and being a new industry, the employees didn't have a lot of resources to help them understand the products that they were tasked with selling to medical patients.
Medical patients would come in and ask them for recommendations, but they wouldn't be able to give confident answers unless they had personally tried these products. I asked them if they thought having a closed social media app to share reviews, photos, and ratings would be helpful, and they said yes, and that's how the first app I ever tried to build was born. I started the process about a month into learning with 100 days of SwiftUI, and I didn't feel anywhere near ready to be building an app yet at this time.
But knowing that the app had the possibility of making their jobs easier made me extremely motivated to get it into their hands. That motivation and having them ask me about the progress kept me from quitting when it got hard. When I first released the app in test flight, only people using the iOS 17 beta could even post reviews for some reason.
Having no experience with Firebase and having to learn image storage and figure out collections was extremely daunting and made me feel like I was way over my head. Once I had users, I got new requests for things like favorites and notifications, and the number of times that I had to struggle with a problem, figure out how to get it working, and then experience the moment that it all came together rapidly leveled me up as a developer. I originally felt crazy for deciding to try and build this app as a first project, but it got done, and seeing my colleagues use that app was one of the proudest moments of my entire journey.
That experience taught me that building apps I was passionate about was key to getting them actually finished. And helping me work through the inevitable frustrations of the development process. So for new developers looking to switch careers, building projects to solve problems from your current or previous careers is a great way to bridge the gap of your experience during interviews.
By using your subject matter expertise to inform your development decisions, you can spin your previous non-dev experience from a negative to a positive. Your personal perspective makes you unique as a job candidate, and when you utilize that uniqueness to create your apps, it's making you unique as a developer. Tip number three, your code doesn't have to be public.
A lot of us deal with anxiety of varying severity, and putting your work out there to be judged can be crippling. The good news is that absolutely nobody has to see your code. At the end of the day, all that matters is that you deliver a smooth and bug-free experience for your users.
That means you don't need to use the newest architecture or the latest frameworks. Nobody has to know how you built your app. If you're more comfortable with Objective-C and you can build out your project in it, do that.
If you haven't learned SwiftUI yet, use UIKit. Nobody has to know how you built the app. It doesn't matter how you get there.
Just make sure that your users are having a positive experience. We often hear about the importance of your GitHub portfolio, but an alternative is keeping your portfolio in the app store. Having an app store portfolio shows prospective employers that you were willing to go the extra mile to get your app idea past app store review and into the hands of actual users.
Another benefit from having an app store portfolio is that your apps don't have to be free. You can create an opportunity for yourself to make additional income however small from making your apps paid or from charging for subscriptions. You can even put a donation button in the app if you would like to keep the app free but allow users to compensate you.
Users paying for your work feels amazing. You feel like your time and effort is valued and that people liked your work enough to pay their hard-earned money for it. The monetary aspect can also encourage you to continue making apps because you know there's an opportunity for financial benefit.
Don't put the pressure on yourself to have perfect code. Just create the best user experience that you can and put your app out there. Tip number four is to challenge yourself with a deadline.
Often one of our biggest challenges as devs is keeping things simple. We want our work to be perfect before it goes out into the public, but we may be spending time building out features that aren't necessary or even utilized by our audience. By setting a deadline, we can force ourselves to focus solely on the most important features that can be done by that deadline.
This can help us with scope creep and keep our first version of the app as close to an MVP as possible, giving us the ability to collect feedback from our users and beta testers before we end up unnecessarily overengineering our applications. For that first app I made for my staff, I wanted to have it submitted to TestFlight by my birthday, August 14th. I had many bugs to work out with the product category filters, the sort order of the posts, and one bug that drove me crazy, where if a user updated their photo, their profile photo, it wouldn't update on the post or the comments that they had made beforehand.
Instead of waiting until I felt like it was perfect to get it out into the hands of the users, I stripped it down to its most basic functionality and made that work well. All you could do when I first released the app was post a photo with a review, a rating, a product category, and a description. Limiting the scope of that MVP allowed me to build momentum, get the project into the hands of users, and then make my future decisions based on actual feedback.
So tip number five is leverage the community. I genuinely do not think I would have made this much progress this quickly without the incredible community I found through Twitter. When I need beta testers, I get volunteers.
When I get stuck on code, I've had people reach out and hop on calls with me to help me debug my code or send me code snippets to help me solve problems. I utilize the community as a huge source of inspiration. As a developer, it's sometimes hard for me to know what's possible without seeing it first.
I've learned about APIs I had no idea about, Swift language features, animations, and all kinds of helpful information along the way. Another underrated benefit of utilizing the community and building in public is the accountability partners you can get when you say you're going to do something. Having people constantly ask you about the progress of that project you said you were going to build is motivating and helps you get on track and keeps you following through.
It's much harder to neglect a project when you have people holding you accountable to finishing it. It's even better when you can generate organic interest in the project before it's released while you're building it. You then know you're not only building it for yourself and a validated project and idea is so much easier to stay motivated about than an unvalidated one.
So how do you find this community? By building and learning in public. One of the big points of emphasis when you do 100 days of Swift UI is sharing your progress with the public.
When other people can see how passionate you are about learning, how hard you're working towards your learning goals, they gravitate towards you. Be authentic, be genuine, and share your progress. Even as a beginner.
Especially as a beginner. You'll attract people into your orbit who are also learning or who want to help you along the way. For me, when I was working on my first app, I couldn't figure out how to structure an enum to get it to do what I needed it to do.
The queen of enums, Jessie Linden, ended up writing code for me to help me and created a solution for me. That's something I will always remember. Both times I couldn't figure out OAuth, Michael Hewlett hopped on Zoom calls with me late at night and helping me figure out solutions that worked.
When I struggled with figuring out network calls, Craig Clayton gifted his course to me that helped me with that topic. So many people have showed up for me with advice, with resources, with offers to beta test and give feedback and encouragement when I feel down. The iOS community has given so much to me, and all I feel like I can do is pay it forward whenever I have the capacity and opportunity to.
Put yourself out there, build and learn in public, and I feel like your chances of success shoot through the roof. So there are so many benefits to turning your ideas, even the small ones, into shipped applications. The process isn't nearly as intimidating as some may make it seem, and the benefits are numerous.
Bet on yourself, build something that makes you happy, and release it. Thank you.
Robin
Great talk. Thank you so much, Daniel. Yeah, you're welcome.
So we have a few questions for you. Okay. Zeno, do you want to kick us off?
I know you probably have one.
Zino
Yeah. You talked about frustration and how hard it can be sometimes. So I know that you said get people interested in your work by giving you deadlines.
You give yourself deadlines, right? And being accountable for the deadlines that you set by talking in public. But how do you deal with frustration?
Because as a newcomer, sometimes you hit a bug that is so infuriating that it makes you want to quit.
Danielle
Yes.
Zino
Absolutely. How do you deal with that?
Danielle
I spoke a lot about leveraging your community, and that was a big part of it for me. One thing that I found is the ability to be vulnerable and just accept that you don't know everything and ask for help. So whenever I hit a hard wall like that, I would just get on Twitter and say, hey, I'm having this issue.
I would detail the issue, and what was really shocking to me was how many people were trying to help once I did that. So I got a lot of offers for help and a lot of people who wanted to help me along the way just by sharing that I was having issues and being stuck.
Zino
And how does that square with what you said about feeling like an imposter? Because when you ask a question, you kind of reinforce the fact that you are not suited to that job. But you also say that that's what helps you.
So how do you square that?
Danielle
Absolutely. I think for me, it was speaking to people who were so much more experienced than me. When you have somebody who's been doing this for 20 years tell you that they still get stuck, that they still have issues, it helps you realize that I've only been doing this for six months.
Of course I'm going to have issues. Of course I'm going to get stuck. So that really helped me out, just having that perspective of people who have been doing this, people I look up to having the same issues that I'm having.
Robin
Let me see. I'm looking at some questions from the audience. Let's see.
Okay. From the audience. Do you check any existing apps on the store before you start developing to see if there's a gap?
Or do you just go straight into building what you like?
Danielle
Yeah. So most of my apps come from personal experience, personal things that I've gone through. I built a law dictionary.
I was a law student and I wanted a better law dictionary. And so when I became an app developer, I built one. I built apps to solve problems that I saw at my job.
I built apps around my hobbies. So it's not really, my apps are all like very personal to me, but I just kind of share them with the world. And that's how I get my inspiration is through my personal experiences.
Robin
Awesome. Well, we have time for maybe one more question. Do you have another one or if not, I have one.
It looks like that's all we have from the audience, but I have one more for you. Okay. How often do you come back around and update your apps?
Because you said that you publish them all as an MVP, but today they're nothing like what they first were.
Danielle
Yeah. So I kind of have in my head what I want an app to look like at the finish line. So it's more so just when I have time to do it.
I like to try to get an app that's close to finish before I start another one, just so that I'm not, you know, building on top of things and putting things on the back burner. I really like to finish one thing or get as close to finish as possible before I start something new. But I kind of have an idea in my head what features I want for this app to have.
And when it first releases, it's not going to have most of those features. So I kind of build myself a roadmap so I can say, okay, I know I want to build this, this, and this, and I try to build myself a roadmap to get that done. Awesome.
Robin
Well, thank you so much.
Danielle
You're welcome.
Robin
A round of applause for Danielle. Thank you.