DEV Community: Steven J. Selcuk

Create AppStore Images with one liner

Steven J. Selcuk — Mon, 09 Mar 2026 09:52:28 +0000

As an iOS developer, the absolute worst part of releasing an app is creating App Store screenshots.

There are expensive micro-SaaS tools out there. But honestly? They just take your money, and you still end up doing a lot of manual work. I am already paying too much money to Digital Ocean and Google Cloud. I don't need this.

Here is my personal solution. It kills two birds with one stone:

First, we automate our App Store screenshots,
Second, we write UI tests and increase our code coverage.

Here is how you can do it, step-by-step:

Step 1: Take Screenshots with XCTest

Write a simple UI test and use XCTest to take a screenshot. Make sure to keep the attachment so Xcode saves it.

let screenshot = XCUIScreen.main.screenshot()
let attachment = XCTAttachment(screenshot: screenshot)
attachment.lifetime = .keepAlways
attachment.name = "AppStore_Home"
add(attachment)

Step 2: Run Your Tests

Just run your UI tests in Xcode (Cmd + U). Xcode will automatically save all these screenshots inside a hidden .xcresult file.

Step 3: Export to Desktop using a Custom CLI Command

Instead of writing a long, messy bash file every time, let's turn this into a simple custom CLI command!

You just need a tool called xcparse (you can install it via Homebrew).

To make it a simple command, open your terminal and add this small function to your ~/.zshrc (or ~/.bash_profile) file:

# Add this to your .zshrc
extract_screens() {
    LATEST_RESULT=$(find ~/Library/Developer/Xcode/DerivedData -name "*.xcresult" -type d -exec stat -f "%m %N" {} + | sort -rn | head -1 | cut -d' ' -f2-)

    mkdir -p ~/Desktop/Screenshots
    xcparse screenshots "$LATEST_RESULT" ~/Desktop/Screenshots

    echo "🚀 Success! Screenshots extracted to your Desktop."
}

Now, restart your terminal. After your tests finish, just type this single command:

$ extract_screens and hit the enter.

Boom! All your App Store screenshots are sitting perfectly on your Desktop. You saved money, saved time, and tested your app. We have a raw screenshot and tot impressed? Totally understandable. The second part will be SVG-based image generation and localization. Click to follow the button. Stay tuned.

How do you currently handle your App Store screenshots? Paying others? Let me know below! 👇

Patterns and Folder Structure for iOS Development

Steven J. Selcuk — Wed, 21 Jan 2026 10:05:56 +0000

Every two years, a design pattern becomes famous. VIPER was the golden boy before. I mean, it was the top %1 popular question for the whiteboarding stage. So what? It was MVC in UIKit times. Now it's MVVM for modern Swift6/SwiftUI/iOS development

Let's talk

It's just naming and putting files in the correct place. Do not get confused with all the mumbo-jumbo and CS666 something. All these patterns only affect your workflow. Not your code. Views are the same views in SwiftUI, nothing new or changed.

Create Domain/Feature-Based Modules

If you know REACT this is what we have been using for decades. Create containers in a name, e.g., Dashboard display, and do stuff here. It can be Login, About, Services, Landing Page, and Onboarding. One Job -> One domain, so you can isolate them from each other

Do not do business logic in Views

The second rule is not put functions except UI related stuff in views. Do it on ViewModel. Same thing again. Separation & isolation.

Use a Common/Shared folder

This is kinda conflicts with a rule, much more important than all this folder thing. DO NOT REPEAT YOURSELF! So create a common/shared folder for reusable components (like in React), views, etc. Use them.

Reality check: Design Patterns and Architecture Designing are Different Things

MVVM is not a superhero. Yea most of the companies/startup and their teams lives with an idea and are ready to fight. But hey, it's just a decision of naming / foldering, that's it. Not System Architecture. Do not confuse. I mean. If you don't have a solid foundation, eventually your view models inflate and explode, or you have to deal with a race condition for 4 hours, and MVVM can't save you from this. Do not get hyped with random letters shows up in your LinkedIn feed.

Final Conclusion

Every two years, fully refactor your code. Maybe ten years ago, it was five. One simple thing you need to keep in mind if you're starting a project, except if you're a newcomer to an existing storyboard-used VIPER project, it's a different story. Good luck with that. How can I make it easy to rewrite/refactor the whole app 2 years later? Question is: How maintainable? How long does it take? If you have an answer for it. Choose whatever you want for "pattern."