Mobile development blogs, tutorials and resources inside!Latest Mobile Dev Insights: iOS, Android, Cross-PlatformAdvertise with Us|Sign Up to the NewsletterMobilePro #229: Thinking in SwiftUIHi ,Good frameworks don't just give you more tools. They give you fewer things to think about.That's part of what makes SwiftUI interesting. Views compose into larger interfaces, state keeps the UI synchronized with data, navigation handles familiar platform behavior, and modifiers let you progressively shape an experience without reaching for piles of boilerplate. This week's article goes back to those fundamentals and shows how a handful of SwiftUI building blocks can take you from a simple screen to interactive, state-driven interfaces, and even back into UIKit when you need it.There's a similar focus on removing everyday friction in this week's news. React Native 0.87 tightens TypeScript support while experimenting with SwiftPM, Jetpack Compose 1.12 improves everything from visuals to startup and testing, and JetBrains' research suggests developer experience itself is helping attract developers to Kotlin. Different ecosystems, same underlying direction: make the foundations better, and developers can spend more time building what matters.TL;DRSwiftUI starts with composition. Text, images, buttons, and even layout containers are views that can be combined into increasingly sophisticated interfaces.Modifiers progressively transform views. Their order matters, and type-safe resources and semantic system colors can make interfaces safer and more adaptable.State makes interfaces reactive. Change a @State value and SwiftUI automatically updates the views that depend on it.Controls bind directly to data. Toggle, Picker, Slider, Stepper, and DatePicker all fit the same state-driven model, keeping the UI and its underlying values synchronized.SF Symbols can communicate state through subtle motion, with effects such as bounce, rotate, breathe, and draw-on.SwiftUI doesn't require abandoning UIKit. UIViewRepresentable, UIViewControllerRepresentable, and coordinators provide a practical bridge when SwiftUI doesn't offer what an existing UIKit component provides.This week’s news cornerJetBrains finds developers are choosing Kotlin for better developer experience: JetBrains’ 2025 Developer Ecosystem research finds that while project requirements drive most programming language migrations, Kotlin stands out as a language developers actively choose for its modern features and better development experience. Java remains Kotlin’s biggest source of new users, while TypeScript, Rust, Python, and Go show strong growth potential across the wider ecosystem.React Native 0.87 makes Strict TypeScript default and adds SwiftPM support: React Native 0.87 makes the Strict TypeScript API the default, upgrades Metro with 2x faster source-map generation and half the memory usage, and introduces experimental Swift Package Manager support as an alternative to CocoaPods for iOS. Android developers also gain AGP 9 support, while new minimum requirements include Node.js 22, Kotlin 2.0+, and compileSdk 37.Jetpack Compose 1.12 brings richer visuals, faster startup, and better testing: Google has released Jetpack Compose 1.12, adding Mesh Gradients, Wide Color Gamut and HDR rendering, richer editable text, named Grid areas, and native Credential Manager integration for passkeys and saved sign-ins. Performance also gets a boost, with startup times now comparable to Views in Google’s benchmarks, alongside new APIs designed to make UI and animation tests faster and less flaky.iOS 27 Public Beta 4 brings Apple closer to final release: Apple has released iOS 27 Public Beta 4, matching Developer Beta 6 and focusing primarily on bug fixes, performance improvements, and UI polish as the final release approaches. Changes include an updated iOS notification animation alongside fixes carried over from earlier betas.A glimpse of BuildWithAI newsletterBuilding with AI is quickly becoming part of every developer's workflow. Each week, Build with AI explores practical AI engineering, agentic development, LLMs, MCP, coding tools, and the techniques shaping modern software development. Here's a glimpse into a recent featured article:The AI-Native Loop: Who Owns the Code Now – Part 2 with Michelle SandfordOur bug-fix experiment is a deliberately mundane one: a TypeScript service exposes a/reportsendpoint withfromandtoquery parameters, and it returns an empty array when a user in Australia/Perth selects the last day of the month. The root cause is a comparison that parses thetovalue as UTC midnight, which falls before the user’s local end of day. It is exactly the kind of slightly embarrassing date bug every engineer has shipped.The repository is a small Node.js service with TypeScript strict mode, Jest, Fastify, and GitHub Actions for CI. ThebuildRangefunction lives insrc/reports/range.ts, and a modestAGENTS.mdfile is already in place.Both runs use the same measures:T1: Time to the first reproducing testT2: Time to a fix merged through CIQ1: Number of distinct edge cases captured by testsQ2: Number of surviving artifacts after the mergeR1: Can a future engineer understand the reasoning without rereading the diff?TipKeep this yardstick visible while you compare Run A and Run B. The important signal is not only speed, it is the quality and durability of the artifacts each run leaves behind.Read more...From Views to UIKit: A Practical Guide to SwiftUI’s Core Building BlocksBuilding an iOS interface used to involve a considerable amount of setup. Even a relatively simple screen could mean writing boilerplate code or configuring views manually in Interface Builder. SwiftUI changed that model by introducing a declarative approach: instead of describing every step required to construct an interface, developers describe what the interface should contain, and SwiftUI takes responsibility for rendering and updating it.That shift is what makes SwiftUI particularly approachable and powerful. Interfaces can be assembled from small, reusable views, organized with layout containers, and refined with modifiers. When application data changes, SwiftUI automatically determines which parts of the interface need to be updated.The fundamentals become easier to understand when they are explored through real interfaces rather than isolated APIs. The chapter SwiftUI Essentials takes that practical route, moving from views and layout to navigation, controls, SF Symbols, and finally interoperability with UIKit. Together, these concepts form a foundation for building modern Apple-platform applications.Start by Thinking in ViewsAlmost everything visible in a SwiftUI interface is a View. Text, images, buttons, controls, and even the containers that organize them participate in the same compositional system.A useful example is a weather profile card. It begins with little more than two Text views displaying a city and its current weather. From there, the interface can gradually grow to include an image, temperature information, spacing, backgrounds, and layered visual elements. This incremental approach demonstrates an important SwiftUI habit: build the smallest working structure first, verify it, and then add presentation and behavior.Three containers do much of the work in everyday layouts:VStack arranges views vertically.HStack arranges them horizontally.ZStack places views on top of one another.These containers become powerful because they can be nested. A vertical layout might contain a horizontal row, which itself contains several vertical columns. A ZStack can place an icon above a gradient, while another ZStack positions that entire composition over a background.The result is an interface built through composition rather than through a large, monolithic view definition.Modifiers then refine those views. Developers can change typography with .font(), establish hierarchy with .foregroundStyle(), control spacing using .padding(), constrain dimensions through .frame(), and introduce backgrounds, clipping, or shadows.Modifier order matters because each modifier effectively transforms the view produced before it. That means applying padding before a background is not necessarily equivalent to adding a background first and padding afterward.Small implementation decisions also improve maintainability. For asset catalog images, for example, the chapter recommends the type-safe ImageResource form such as Image(.cloudAndSun) rather than relying entirely on string-based asset names. This provides autocomplete and compile-time validation instead of allowing a mistyped image name to fail silently at runtime. Semantic system colors are similarly valuable because they adapt automatically to light mode, dark mode, and high-contrast environments.Turn Static Screens into Interactive AppsA useful interface needs more than layout. Users must be able to perform actions and move between screens.SwiftUI addresses those requirements primarily through Button, NavigationStack, and NavigationLink. A NavigationStack manages a hierarchy of screens, while a NavigationLink pushes another view onto that hierarchy. SwiftUI handles much of the expected platform behavior, including navigation transitions and the back button, without developers having to recreate it manually.The chapter demonstrates these concepts through a ButtonShowcase application with separate screens for button styles, semantic roles and tinting, and border shapes.Button styling is not only cosmetic. SwiftUI supplies styles ranging from .bordered and .borderedProminent to .plain, .borderless, .glass, and .glassProminent. Developers can also communicate meaning through roles such as .destructive, .cancel, and .close. A destructive role, for example, receives system treatment that helps communicate the consequences of the action.Additional modifiers such as .tint() and .buttonBorderShape() make it possible to adjust emphasis while still retaining system behavior. The important principle is that visual treatment, semantic meaning, and the code executed by the button remain distinct concerns.State then connects actions to visible results.A property marked with @State represents information owned by a view. When that value changes, SwiftUI identifies the dependent views and updates them automatically. A button tap might update a selected style, for example, causing a label or icon elsewhere on the screen to change immediately. Developers describe the relationship between state and interface rather than manually instructing individual controls to redraw.Build Controls Around the DataThe same state-driven model becomes especially clear in settings screens.SwiftUI includes dedicated controls for common input patterns: Toggle for Boolean values, Picker for selections, Slider for continuous ranges, Stepper for discrete increments, and DatePicker for dates and times. Instead of maintaining one value inside the interface and another in the application model, each control can bind directly to a @State property.A settings-style Form provides a natural environment for those controls. In the chapter’s ControlsShowcase example, toggles manage preferences such as notifications and sound, pickers handle themes and colors, a slider controls volume, a stepper changes a badge count, and a graphical date picker selects a reminder date. The central pattern stays consistent: the control receives a binding, reads the current value, and writes changes back to it.This is one of the most useful patterns to internalize in SwiftUI. UI and state remain synchronized by design.SF Symbols complement these controls by providing a large collection of system icons that behave much like text. They respond to fonts and foreground styles and can appear in monochrome, hierarchical, palette, or multicolor rendering modes. Developers can also apply symbol variants and effects to communicate changes more clearly.That allows interface feedback to remain subtle but expressive. A bell can bounce after a tap, an activity icon can rotate while work is ongoing, or a speaker icon can transition smoothly between muted and unmuted states. The chapter distinguishes between one-shot effects such as .bounce and indefinite effects such as .wiggle, .rotate, .breathe, and .drawOn, which continue while their active state remains true.SwiftUI Does Not Mean Leaving UIKit BehindModern SwiftUI covers most common interface requirements, but existing UIKit APIs and third-party components remain important. Fortunately, adopting SwiftUI does not require abandoning them.UIViewRepresentable allows a UIKit view to participate in a SwiftUI interface, while UIViewControllerRepresentable performs the same role for UIKit view controllers. Both follow a similar lifecycle: one method creates and configures the UIKit component, and another receives subsequent SwiftUI state changes and updates the component accordingly.The chapter demonstrates this with a TextPreviewer app. A UILabel is wrapped with UIViewRepresentable, allowing text and font size controlled by SwiftUI state to update the UIKit label in real time. A UIFontPickerViewController is then wrapped with UIViewControllerRepresentable.When delegate callbacks are required, a Coordinator becomes the bridge back from UIKit to SwiftUI. It can receive the UIKit event, update a SwiftUI binding, and trigger the normal SwiftUI rendering cycle.A useful rule emerges from this interoperability model: perform expensive one-time configuration in the representable’s creation method and keep the update method focused on lightweight changes to data. From the surrounding SwiftUI application’s perspective, the wrapped component can then behave much like any other SwiftUI view.UIKit interoperability should still be deliberate. Before wrapping an older UIKit API, it is worth checking whether SwiftUI now provides a native equivalent. Where it does not, or where a specialized library still depends on UIKit, the representable protocols provide a practical migration path rather than forcing an all-or-nothing rewrite.A Foundation for Real SwiftUI DevelopmentSwiftUI becomes much less mysterious once its recurring ideas are visible.Compose interfaces from small views. Arrange those views with stacks and containers. Refine them with modifiers. Keep changing information in state and bind controls to it. Let navigation describe relationships between screens. Use SF Symbols and semantic system styling to create interfaces that naturally fit Apple platforms. And when SwiftUI does not expose the component you need, bridge to UIKit instead of working around the framework.Taken together, these techniques move SwiftUI beyond the idea of a convenient UI syntax. They establish a consistent way of thinking about application interfaces: describe the screen, connect it to state, and let the framework manage the updates.That mental model is the real SwiftUI essential—and once it becomes familiar, increasingly sophisticated iOS interfaces can be built from the same small set of ideas.This article is based on SwiftUI Cookbookpublished by Packt.📚Go DeeperIf you're ready to take your SwiftUI skills further and build polished, production-ready Apple apps, SwiftUI Cookbook provides practical, recipe-based guidance for creating modern interfaces, handling navigation and user interactions, managing app data, and integrating SwiftUI with UIKit to solve real-world development challenges.🧩 Learn SwiftUI through practical recipes that progress from fundamentals to advanced APIs✨ Build modern iOS apps with iOS 27 APIs and the new Liquid Glass design📊 Explore Swift Charts, SwiftData, animations, networking, and testingSwiftUI CookbookPre-order now at $44.99📢 Important: MobilePro is Moving to SubstackWe’ll be moving MobilePro to Substack soon. From that point forward, all issues will come frompacktmobilepro@substack.com.To ensure uninterrupted delivery, please whitelist this address in your mail client. No other action is required.You’ll continue receiving the newsletter on the same weekly cadence, and on Substack you’ll also gain more granular control over your preferences if you wish to adjust them later.💭 Let’s TalkWhat's the SwiftUI concept that took the longest to finally "click" for you?Reply and let us know.Advertise with usInterested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email and our team will get in touch with next steps.Cheers,Nithya Sadanandan and Runcil Rebello,Editors-in-Chief, MobilePro*{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0}#converted-body .list_block ol,#converted-body .list_block ul,.body [class~=x_list_block] ol,.body [class~=x_list_block] ul,u+.body .list_block ol,u+.body .list_block ul{padding-left:20px} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;display:none;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}.social_block .social-table{display:inline-block!important}}
Read more