# iOS development Published articles for iOS development. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How To Get Apple To Respond In Days On AppStore Issue DevFeed: [How To Get Apple To Respond In Days On AppStore Issue]() Original publisher: [Read original article]() Author: Elye - A Dev By Grace Published: 2026-08-26T10:40:01Z Content type: tutorial Language: en Sources: [Mobile App Development Publication - Medium]() Topics: [iOS](), [Mobile](), [Development]() Tags: [app-development](), [apple](), [developer](), [how-to](), [ios-app-development](), [ios-development](), [issue](), [mobile](), [mobile-app-development](), [software-development]() ### AI overview The article describes an App Store submission issue in which the Submit spinner stops and the process cannot continue. It presents this as a practical account of what to do when Apple does not respond for weeks. ### Source excerpt A True Story: What To Do When You're Stuck With AppStore Issue for Weeks Continue reading on Mobile App Development Publication " ## Migrating a Flutter Application from CocoaPods to Swift Package Manager DevFeed: [Migrating a Flutter Application from CocoaPods to Swift Package Manager]() Original publisher: [Read original article]() Author: iamgirya (Яндекс) Published: 2026-07-13T07:01:51Z Content type: tutorial Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [Flutter](), [cocoapods](), [swift-package-manager](), [iOS](), [Dart](), [macOS](), [Package manager]() Tags: [cocoapods](), [dart](), [flutter](), [ios](), [ios-development](), [macos](), [swift](), [swift-package-manager](), [swiftpm]() ### AI overview A practical guide to migrating Flutter applications from CocoaPods to Swift Package Manager. It covers dependency-graph analysis, plugin migration, dependency resolution, incremental migration, duplicate transitive dependencies, and successful iOS or macOS builds, including scripts for analysis and plugin conversion. ### Source excerpt Flutter активно движется в сторону Swift Package Manager (SPM) и, как и весь Swift-мир, постепенно отказывается от CocoaPods. Сам Flutter описывает миграцию в два шага: включить флаг flutter config --enable-swift-package-manager и запустить сборку. Если после этого приложение собирается и в консоли появляется предложение deintegrate CocoaPods -- вы счастливчик. Если нет, добро пожаловать под кат. Привет! Меня зовут Даниил Гиренко, я Flutter-разработчик в Яндекс Про. Проект по переводу нашего супераппа с CocoaPods на Swift Package Manager оказался одним из самых сложных и долгих в моей карьере программиста. Весь мой пережитый ужас опыт я решил выразить в этой статье, чтобы решившиеся на миграцию разработчики (или агенты) понимали, какие подводные камни их ждут. Буду рад, если ваш проект займёт недели, а не месяцы, как у меня. В этой статье -- полноценный гайд по миграции любого Flutter-приложения. Разберём граф зависимостей, научимся мигрировать плагины, зарезолвим зависимости и доберёмся до успешного билда. Внутри есть готовые скрипты для анализа и автоматического перевода плагинов, множественные нюансы миграции и рассказы о моих костылях. Читать далее ## Leveraging AI to build a faster iOS CI system DevFeed: [Leveraging AI to build a faster iOS CI system]() Original publisher: [Read original article]() Author: Muhieddine EL Kaissi Published: 2026-04-21T18:16:01Z Content type: article Language: en Sources: [Thumbtack Engineering - Medium]() Topics: [CI/CD](), [Testing](), [iOS](), [AI-assisted coding]() Tags: [ai](), [ai-assisted-coding](), [ci-cd](), [continuous-integration](), [developer](), [developer-productivity](), [ios](), [ios-development](), [mobile](), [pipeline](), [testing]() ### AI overview Thumbtack describes Smart Test Selection, an iOS CI system that reduces pipeline time by running only tests relevant to each pull request. The article explains why parallelization stopped scaling, including node contention, large test suites, and slow snapshot and UI tests, while noting that AI-assisted coding could increase CI demand. ### Source excerpt Every iOS pull request at Thumbtack used to wait 30 to 40 minutes for Continuous Integration (CI) -- sometimes over an hour on Fridays. We built Smart Test Selection (STS) to cut that in half. Here's how. I'm a Senior Software Engineer on the iOS Infrastructure team. We own the CI/CD pipelines, build tooling, and shared frameworks that keep Thumbtack's apps shipping reliably. We also build AI-powered developer tooling -- 35+ AI Agent Skills, MCP integrations for Jenkins, Figma, Firebase, and Xcode -- that help the broader iOS team ship faster. Over the past few quarters, we built Smart Test Selection (STS), a system that reduces CI time by running only the tests that matter for each pull request. Why Full-Suite Testing Stopped Scaling Before STS, we had already optimized CI through parallelization -- running consumer, pro, and shared framework tests on separate nodes, and splitting snapshot tests across multiple simulator clones. But parallelization hit a ceiling. The more nodes we spread CI across, the more engineers had to wait for free nodes, cancelling out the speed gains. Snapshot tests dominated the suite but couldn't be split further without diminishing returns, and UI tests were inherently slow per-test. We needed a fundamentally different approach: run fewer tests, not run the same tests faster. Every iOS PR ran the full test suite for each affected app. We have three main targets -- a consumer app, a pro app, and a shared framework -- totaling 1,500+ test classes. The pipeline already skipped unaffected apps (a change to the consumer app would not run pro app tests), but within each affected app, every test ran regardless of what specifically changed. A one-line bug fix in one screen would trigger all 400+ tests for that entire app. This was becoming unsustainable. Human-generated code was already putting CI at the limit due to ever-increasing code size and test counts. We had increased our CI node count multiple times to keep up with demand, but each expansion ## Why Waiting Feels Slow -- and How We're Using Real-Time Signals to Change That DevFeed: [Why Waiting Feels Slow -- and How We're Using Real-Time Signals to Change That]() Original publisher: [Read original article]() Author: Global Technology Published: 2026-03-31T14:17:27Z Content type: article Language: en Sources: [McDonald's Technical Blog - Medium]() Topics: [iOS](), [User Experience](), [user experience design]() Tags: [customer-experience](), [digital-experiences](), [ios](), [ios-development](), [mobile-development](), [real-time](), [technology](), [user-experience](), [user-experience-design]() ### AI overview McDonald's product, design, and engineering teams describe using iOS Live Activities to provide real-time order updates on the Lock Screen and Dynamic Island. The backend-driven platform aims to reduce uncertainty during waits and support reusable trackable experiences across the digital ecosystem. ### Source excerpt A look into how our team turned uncertain wait moments into confident, glanceable experiences for guests in iOS using Live Activities. by: Maitree Shukla, Product Manager, Menu Browse, Alex Timmler, Director, Product Management, Nick Wilczynski, Sr Manager, Engineering Tech Lead, and Connor Sheehan, Software Engineer Quick Bytes: Digital transparency directly shapes perceived speed -- and uncertainty can make even fast experiences feel slow Live Activities provide customers with real-time order updates directly on the iOS Lock Screen and Dynamic Island Built as a reusable, backend-driven platform, this work unlocks future innovation across McDonald's digital ecosystem In a digital experience, speed isn't just about how fast an order is prepared -- it's about how fast it feels. When customers lack visibility into what's happening with their order, uncertainty creeps in, and even short waits can feel longer than they are. Our Product and User Experience Design teams set out to reduce that uncertainty by delivering real-time, glanceable updates through iOS Live Activities. The concept of Live Activities stemmed from one guiding question the team asked ourselves: How might we make the ordering experience feel as frictionless as possible? From there, that question naturally led to others. How do we make waiting feel faster? How can we be more transparent with customers? And how can we reduce moments of uncertainty along the way? To address those questions, we turned to Live Activities -- a capability built into iOS -- that enables real-time order updates on the Lock Screen and Dynamic Island, using premium screen real estate to provide reassurance without opening the app. It's a simple but powerful way to reinforce McDonald's reputation for leadership in convenience and speed, across both physical and digital experiences. To deliver this experience, we needed strong foundations: updates must be timely, flows can't disrupt restaurant operations, edge cases must be handled gra ## The KotlinConf 2026 talks that we're excited about - Kevin Schildhorn DevFeed: [The KotlinConf 2026 talks that we're excited about - Kevin Schildhorn]() Original publisher: [Read original article]() Published: 2026-03-03T00:00:00Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Kotlin](), [compose-multiplatform](), [kotlin-native](), [iOS development](), [ui](), [amazon](), [Library]() Tags: [amazon](), [android](), [compose-multiplatform](), [ios](), [ios-development](), [js](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [kotlinconf](), [library](), [talks](), [ui]() ### AI overview A Touchlab commentary selects KotlinConf 2026 talks covering Kotlin/Native integration, Kotlin Multiplatform project organization and compilation times, Compose Multiplatform UI performance and animation, and iOS development with KMP at Amazon. ### Source excerpt The KotlinConf 2026 schedule was recently announced and there are a lot of talks to be excited about. We decided to compile a list of the talks we're excited to see. ## Ship It Right: A Swift Package Quality Checklist. Part 3 of 3. DevFeed: [Ship It Right: A Swift Package Quality Checklist. Part 3 of 3.]() Original publisher: [Read original article]() Author: Oleksii Kolomiiets Published: 2026-01-06T15:57:22Z Content type: opinion Language: en Sources: [Snapp Mobile - Medium]() Topics: [Swift](), [Tutorial](), [Documentation]() Tags: [documentation](), [ios-development](), [marketing](), [open-source](), [swift](), [swift-package-index](), [swift-package-manager](), [tutorial](), [work]() ### AI overview The final part of a Swift package quality checklist argues that visibility and developer onboarding are essential after documentation, quality checks, community processes, and releases are in place. It explains how DocC tutorials can provide interactive, step-by-step onboarding and distinguishes tutorials from explanatory articles. ### Source excerpt Parts 1 and 2 established everything you need for a solid, maintainable Swift package: documentation, automated quality checks, contributor-friendly processes, and professional releases. Your package is technically excellent and easy to contribute to. But here's the problem: good code doesn't promote itself. I've experienced this with every project. I spent weeks building SwiftFormatLintPlugin, writing documentation, setting up CI, creating examples. Then I pushed it to GitHub and... waited. Nothing happened. No stars, no issues, no discussions. Photo by Jakub Zerdzicki on UnsplashThis series is for Swift developers turning internal packages into polished public repositories. Parts 1-2 covered documentation, quality, and community. This final part focuses on growth and visibility. The same code, after I actually shared it on social media, started getting traction. Developers discovered it. The difference wasn't the code -- it was visibility. You can build the best Swift framework in the world, but if developers don't know about it, the impact is zero. Tutorials: Interactive Learning with DocC We have DocC to create tutorials -- quick-starts or how-tos with code and screenshots in a playful way. Tutorials are interactive, step-by-step guides that walk users through actual implementation. They're more engaging than articles and more structured than example code. I saw the impact tutorials can have when we added them to SnappTheming. Instead of users asking "how do I get started?" in issues, they will work through the tutorial and show up with specific, advanced questions. The tutorial does the heavy lifting of onboarding. Tutorials vs Articles Both are valuable, but they serve different purposes: Tutorials -- "Let's build something together." Interactive, step-by-step, with specific outcomes. Best for getting started or learning a workflow. Articles -- "Here's how this works." Explanatory, reference-oriented. Best for understanding concepts or exploring features. Use tutori ## Ship It Right: A Swift Package Quality Checklist. Part 1 of 3. DevFeed: [Ship It Right: A Swift Package Quality Checklist. Part 1 of 3.]() Original publisher: [Read original article]() Author: Oleksii Kolomiiets Published: 2026-01-05T08:49:11Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [Swift](), [Documentation](), [swift-package-manager](), [GitHub Actions](), [Open Source](), [Automation](), [Code]() Tags: [automation](), [build](), [documentation](), [github-actions](), [guides](), [ios-development](), [open-source](), [swift](), [swift-package](), [swift-package-manager](), [tests]() ### AI overview This tutorial presents a checklist for turning internal Swift Package Manager packages into polished public repositories. Part 1 focuses on documentation and README design, including installation instructions, usage examples, badges, links to full documentation, and licensing, while also introducing quality automation, community infrastructure, and discoverability. ### Source excerpt I still remember the moment I decided to open-source my first Swift Package Manager plugin. The code worked perfectly in our internal projects at Snapp, but making it public-ready? That was a different story. I spent the next week adding DocC documentation, setting up GitHub Actions CI, writing example apps, and addressing edge cases I'd been ignoring because "it worked for us". Photo by Vooglam Eyewear on UnsplashThis series is for Swift developers turning internal packages into polished public repositories -- covering documentation, quality, and community setup. Here's the thing: most developers know how to write good code. But there's a massive gap between "code that works" and "a repository that welcomes users and contributors." That gap includes: Documentation that assumes zero context -- Your README.md makes sense to you, but will it help someone discovering your project at 2 AM? Quality automation -- Are you manually checking code style, or does your CI catch issues before they reach main? Community infrastructure -- When someone wants to contribute, is the path clear or confusing? Discoverability -- Great code that nobody knows about might as well not exist. I learned these lessons by studying successful repositories, discussing best practices with experienced coworkers, and developing my own sense of what makes a project polished versus what might fall short. Let's start with the most visible part of any repository -- the README. README: Keep It ConciseREADME is the door, not the whole house. Follow a simple rule: the README should answer three questions: What does this do? How do I install it? Where can I learn more? What Belongs in a README 1. Title and One-Line Description -- make it crystal clear what this is. # SwiftFormatLintPlugin A Swift Package Manager plugin that integrates swift-format linting and formatting into your build workflow. 2. Key Badges -- status, version, license, supported platforms etc. [![Tests](https://github.com/oleksiikolomiietssnapp/Me ## Why Legacy Xcode Projects May Benefit from Replacing Groups with Folders DevFeed: [Why Legacy Xcode Projects May Benefit from Replacing Groups with Folders]() Original publisher: [Read original article]() Author: Elye - A Dev By Grace Published: 2025-12-07T13:07:57Z Content type: article Language: en Sources: [Mobile App Development Publication - Medium]() Topics: [Xcode](), [legacy](), [iOS]() Tags: [apple](), [coding](), [ios](), [ios-development](), [legacy](), [mobile-app-development](), [structure](), [xcode](), [xcode-16]() ### AI overview This article explains how Xcode project file organization differs between Groups and Folders. It notes that projects created before Xcode 16 use Groups by default, while new projects use Folders, and introduces reasons for considering Folders in legacy projects. ### Source excerpt Seven Reasons Folders Are Better -- Especially for Legacy Projects Continue reading on Mobile App Development Publication " ## Building Your First Kotlin Multiplatform App: From Setup to iOS App Store with Compose Multiplatform (2025 Guide) DevFeed: [Building Your First Kotlin Multiplatform App: From Setup to iOS App Store with Compose Multiplatform (2025 Guide)]() Original publisher: [Read original article]() Published: 2025-07-28T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [compose-multiplatform](), [Kotlin Multiplatform](), [Tutorial](), [cross-platform](), [iOS](), [Kotlin](), [Android](), [Jetpack Compose](), [Mobile](), [Deployment](), [Databases]() Tags: [2025](), [android](), [android-studio](), [app-store](), [architecture](), [build](), [business-logic](), [clean-architecture](), [compose-multiplatform](), [cross-platform](), [deployment](), [development](), [guide](), [implementation](), [ios](), [ios-development](), [kotlin](), [kotlin-multiplatform](), [multiplatform](), [setup](), [workshop-learning-programming]() ### AI overview A tutorial for building Kyklos, a Kotlin Multiplatform subscription-tracking app with shared Compose Multiplatform UI and business logic for Android and iOS. It covers project setup, Clean Architecture, SQLDelight database integration, Material Design 3, testing, and deployment. ### Source excerpt A comprehensive guide to building your first Kotlin Multiplatform app using Compose Multiplatform, covering setup, development, and deployment ## Укрощаем асинхронный код с помощью async/await DevFeed: [Укрощаем асинхронный код с помощью async/await]() Original publisher: [Read original article]() Author: McDee (hh.ru) Published: 2025-04-29T06:50:38Z Content type: tutorial Language: ru Sources: [HeadHunter RU]() Topics: [async/await](), [async](), [iOS](), [Swift]() Tags: [async](), [await](), [ios](), [ios-92ecabba3495](), [ios-development](), [swift](), [tag-218f4e01a540](), [tag-7b7ea8dda2d4](), [tag-ae979152fd5d](), [tag-f538878e20ff]() ### AI overview This Russian-language tutorial explains async/await for asynchronous and multithreaded programming in iOS applications with Swift. It introduces the core concepts and compares async/await with GCD, highlighting code readability and error handling. ### Source excerpt Привет! Меня зовут Андрей Максимкин, я iOS-разработчик в hh. Мы в команде активно используем async/await подход при написании нового кода, а также активно применяем при переписывании старого. В процессе работы сталкивались с некоторыми интересными и не самыми очевидными моментами -- их и рассмотрим в статье. Работа с различными потоками -- очень важная часть разработки мобильных приложений под iOS. Грамотное распределение нагрузки положительно влияет на скорость работы приложения, а значит, и на пользовательский опыт. До Swift 5.5 для работы с многопоточностью в основном использовали фреймворки GCD и NSOperation. Начиная с версии Swift 5.5 стал доступен функционал async/await. В статье мы кратко расскажем о базовых принципах данного подхода и сделаем акцент на проблемах и особенностях, которые необходимо знать при написании кода. Информация будет полезна тем, кто уже знаком с функционалом async/await, а некоторые примеры могут быть интересны и более продвинутым разработчикам. Поехали! ## Ideal iOS KMP Setup - Kevin Galligan DevFeed: [Ideal iOS KMP Setup - Kevin Galligan]() Original publisher: [Read original article]() Published: 2024-05-18T00:00:00Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [iOS development](), [Development](), [Xcode](), [Tooling](), [Developer experience](), [Kotlin](), [openjdk](), [SDK](), [configuration](), [Homebrew](), [debugging](), [Open Source]() Tags: [configuration](), [debugging](), [developer-tools](), [gradle](), [homebrew](), [installation](), [ios-development](), [java](), [kotlin](), [open-source](), [openjdk](), [security]() ### AI overview A practical guide to setting up an iOS development environment for Kotlin Multiplatform (KMP), covering JVM installation and management, Xcode version management, and Touchlab's Kotlin Xcode Plugin for Kotlin-aware debugging. ### Source excerpt To maximize your iOS developer experience with KMP, you'll want to install the best tools available and configure them appropriately. There are many options available, but this is Touchlab's preferred iOS development setup. ## The fundamentals of iOS at Revolut DevFeed: [The fundamentals of iOS at Revolut]() Original publisher: [Read original article]() Author: Illia Kucheriavyi Published: 2024-05-14T11:41:25Z Content type: tutorial Language: en Sources: [Revolut Engineering]() Topics: [iOS](), [iOS development](), [feature flags](), [Mobile](), [SDKs](), [CI/CD](), [experiments](), [Development](), [Agile](), [Testing](), [releases]() Tags: [agile](), [continuous-delivery](), [continuous-integration](), [development](), [development-process](), [experiments](), [feature-flags](), [fundamentals](), [ios](), [ios-development](), [releases](), [revolut](), [sdks](), [software-engineering](), [testing]() ### AI overview This article describes Revolut's iOS development practices, covering its applications and SDKs, weekly App Store updates, continuous integration and delivery, feature flags, gradual rollouts, rollback procedures, and experimentation with statistical measurement. ### Source excerpt Let's take a look behind the scenes of the iOS development at Revolut, where we strive to provide exceptional financial services and seamless customer experiences for the customers who rely on our iOS apps to manage their financial lives. We believe that it's possible to deliver high-quality software, fast. To achieve this we follow a set of important principles and apply a number of modern agile practices, mainly inspired by XP (eXtreme Programming). Deliver fast Currently, on the iOS platform, we have both applications and SDKs. Here's a list of what's live: Revolut, Revolut <18, Revolut Business, Revolut POS and Revolut Pay SDK. All iOS applications are updated in the App Store on a weekly basis. We operate on the principles of continuous integration and continuous delivery to swiftly deliver new functionality to customers -- as soon as a feature or part of it is ready. We've built our own in-house framework for feature-based releases. According to our process, the Product Owner specifies a feature to be enabled starting from a selected version of the application. Then both the application version and its features are rolled out gradually, starting with a small percentage of our customer base. These two approaches -- feature flagging and gradual version and feature rollout -- enable delivering value to customers with the minimum amount of risk. If anything goes wrong, the flag will be turned off or the older version will be re-submitted as rollback, to remove the problematic change. Moreover, feature flags allow team members to easily switch between different user experiences, compare them, or turn them on and off for testing. We've also developed an in-house experimentation platform that allows teams to experiment with new features and measure their impact using predefined metrics in a statistically significant way. This platform guarantees that experiments are properly set up, and that results are produced using a robust statistical framework. All ideas are teste ## Bumble chooses Tuist for iOS project scaling after comparing SPM and Bazel DevFeed: [Bumble chooses Tuist for iOS project scaling after comparing SPM and Bazel]() Original publisher: [Read original article]() Author: Jonathan Crooke Published: 2024-03-12T15:23:14Z Content type: comparison Language: en Sources: [Bumble Tech]() Topics: [Tuist](), [iOS development](), [bazel](), [swift-package-manager](), [Xcode]() Tags: [bazel](), [ios-development](), [swift-package-manager](), [tuist]() ### AI overview In the final part of Bumble's build and project-management overhaul, the team explains why it chose Tuist over Swift Package Manager and Bazel for its iOS project-scaling needs. It found SPM's Xcode integration too slow at its scale and considered Bazel powerful but costly to adopt and maintain. ### Source excerpt Scaling iOS at Bumble: Part 3/3 -- Results and Developer Quality of LifeRecap This is the third and final post in a series on our 2022 & 23 build and project management overhaul. We investigated whether one (or none!) of Swift Package Manager (SPM), Tuist or Bazel would be the tool to overcome our project scaling challenges. In the first post we explained the state-of-play coming into this project. In the second we discussed the results of our proofs of concept. In this post we will explain our conclusions, and talk about the migration project itself. The decisionWe chose Tuist It shouldn't be much surprise that we didn't choose SPM. In fact, we found it to be entirely unsuitable for our use case. This isn't to say that SPM is a poor tool in general -- far from it. Initially we would have preferred to adopt it, however we couldn't ignore the fact that, at least regarding its Xcode-integration, SPM exhibits unacceptably poor performance for our use case, and at our current scale; and this is before we consider our expected future scaling! For those starting new, or smaller projects, SPM seems to provide a nice user experience. However, it also deserves to be regarded as a "first-party CocoaPods". It serves a very similar use-case, and may lead to similar performance drawbacks. Bazel was a different matter. It is undoubtedly a powerful tool, but is a high-investment choice; compared to both SPM and Tuist it diverges much from the traditional iOS development experience, increasing disruption for developers. Also, since Bazel experience is still quite uncommon, this adds extra onboarding load for new team members. We also need to support and maintain infrastructure internally; we have small infrastructure teams and Bazel presents concerns about poor bus factor for a tool that is a single point of failure. During our proof of concept it became clear that in spite of its power, Bazel would be costly for us in the short term. In comparison, Tuist hit a sweet spot between the ## Scaling iOS at Bumble: Part 1/3 -- The Challenges DevFeed: [Scaling iOS at Bumble: Part 1/3 -- The Challenges]() Original publisher: [Read original article]() Author: Jonathan Crooke Published: 2024-01-31T16:10:21Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [iOS](), [iOS development](), [Swift](), [modules](), [Mobile](), [Tooling](), [Development]() Tags: [badoo](), [bff](), [code](), [development](), [ios](), [ios-development](), [modules](), [swift](), [tooling]() ### AI overview The first article in a three-part series explains the challenges of scaling iOS production apps at Bumble Inc. It introduces the company's medium-scale iOS development context, including dozens of engineers, hundreds of modules, more than 100 feature workspaces, millions of lines of Swift, and extensive custom tooling. ### Source excerpt Scaling iOS at Bumble: Part 1/3 -- The ChallengesIntroduction This article is the first in a series of three. We'll be presenting work undertaken during 2022 and 2023 aimed at tackling the challenges of scaling our iOS production apps. Who are we? Bumble Inc. is the parent company of Bumble, Badoo, Fruitz and Official. The Bumble platform enables people to build healthy and equitable relationships, through kind connections. Founded by CEO Whitney Wolfe Herd in 2014, Bumble was one of the first dating apps built with women at the centre and connects people across dating (Bumble Date), friendship (Bumble BFF) and professional networking (Bumble Bizz). Badoo, which was founded in 2006, is one of the pioneers of web and mobile dating products. Fruitz, founded in 2017, encourages open and honest communication of dating intentions through playful fruit metaphors. Official is an app for couples that promotes open and honest communication between partners and was founded in 2020. Who is this for? This blog post series is aimed squarely at teams operating at scales similar to ours. So what is our scale? Scale at Bumble Inc. iOS development at Bumble Inc. is certainly not small! We have: Dozens of engineers Hundreds of modules 100+ feature workspaces Millions of lines of Swift, with a dusting of ObjectiveC for old time's sake 🙃 Tens of thousands of lines of custom tooling code Lots of modularity, and of a quite high standard Just a tiny section of our module graph This might seem to readers as a pretty large scale. However in this article series we'll be considering Bumble Inc. as a medium scale team. So why is that? "Medium" sized teamsWe've chosen this medium terminology to emphasise the "in-between" state that teams can fall into in the iOS ecosystem. On one hand you have the small team; the startup, the individual Developer. Apple's Developer marketing often seems oddly focussed on these kinds of teams! They're very happy with the out-of-the-box Developer experience (and w ## Webinar Recap: iOS Development with Kotlin Multiplatform DevFeed: [Webinar Recap: iOS Development with Kotlin Multiplatform]() Original publisher: [Read original article]() Published: 2023-12-05T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [iOS development](), [Kotlin](), [Swift]() Tags: [ios-development](), [kotlin](), [kotlin-multiplatform](), [swift]() ### AI overview A webinar recap covering iOS development with Kotlin Multiplatform, including Swift/Kotlin interoperability and related tools and resources. ### Source excerpt In this webinar, Touchlab's own Tadeas Kriz and JetBrains' Pamela Hill guided us through iOS development with Kotlin Multiplatform. They explored the current state of Swift/Kotlin interop and highlighted tools and resources that may make your journey easier. ## iOS development with JetBrains Fleet DevFeed: [iOS development with JetBrains Fleet]() Original publisher: [Read original article]() Author: Romain Boisselle Published: 2023-11-26T19:17:05Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [jetbrains](), [ide](), [SwiftUI](), [iOS development](), [User interface design]() Tags: [appcode](), [how-to](), [ide](), [ios](), [ios-app-development](), [ios-development](), [jetbrains](), [jetbrains-toolbox](), [swift](), [swiftui](), [xcode]() ### AI overview A tutorial on using JetBrains Fleet for iOS development with SwiftUI. It explains how Fleet supports code navigation, refactoring, collaboration, and running iOS applications, while noting that Xcode remains necessary for tasks such as project configuration, signing, and dependency management. ### Source excerpt Farewell, AppCode; we've found a worthy replacement. This article is intended to demonstrate how to use JetBrains Fleet for the development of Swift/UI applications, including SwiftUI previews. For those who may not know about JetBrains, it is an amazing company that builds tools for developers, such as IntelliJ IDEA or Kotlin. To me, JetBrains has always provided tools that exceeded my developer expectations, even when those tools are considered "not stable." A year ago, JetBrains announced Fleet, a brand new distributed and polyglot IDE. While many people saw it as just another VSCode IDE, I knew it would become more than that. Bringing collaborative work for remote developers and providing multiple language support out-of-the-box is a real game-changer. And if you've already tried a JetBrains IDE, you know that they are serious about developer productivity! In the meantime, a year ago, they discontinued AppCode, an underrated IDE for working within the Apple ecosystem. AppCode was particularly helpful for developers who found it challenging to adjust to alternative IDE workflows, such as XCode. With Fleet, you will experience easy code navigation, refactoring, collaboration, and support for a wide range of languages and project types, including SwiftUI applications. Let's be honest, you won't completely escape from Xcode -- there are still essential tasks like project configuration, signing, and package dependency management that require its user interface. However, for the majority of your coding sessions, you'll find that you won't need it anymore. Edit and run your iOS app from Fleet Let's start by installing Fleet using the JetBrains Toolbox. This is the easiest way to manage and upgrade your JetBrains IDEs in one place. JetBrains Toolbox -- IDE version management Once Fleet installed, you can either use your own SwiftUI project or clone the following GitHub project created for this article's purpose. https://github.com/KodeinKoders/playground-fleet-swiftui Jet ## Creating a macOS app with Haskell and Swift DevFeed: [Creating a macOS app with Haskell and Swift]() Original publisher: [Read original article]() Published: 2023-11-10T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Swift](), [SwiftUI](), [interoperability](), [Development](), [macOS](), [Library](), [iOS](), [iOS development](), [Xcode]() Tags: [development](), [haskell](), [interoperability](), [ios-development](), [library](), [macos](), [swift](), [swiftui](), [tutorial](), [xcode]() ### AI overview This tutorial series explains how to build a native Apple-platform application with a SwiftUI interface and Haskell-based data and logic. The first part covers setting up a Haskell foreign library, exposing a function through the C FFI, compiling and linking it with a Swift executable, and calling it from a SwiftUI app. ### Source excerpt Contents 1 Hello, Swift, it's Haskell! 1.1 Setting up the SwiftUI app 1.2 Setting up a Haskell foreign library 1.3 Linking the Haskell library with the executable 1.4 The RTS must be initialized 2 Remarks 2.1 Further Reading This is the first part of an in-depth guide into developing a native applications for Apple platforms (macOS, iOS, etc.) using Haskell with Swift and SwiftUI. This is the first in a series of blog posts - covering the set-up required to call Haskell functions from Swift in an XCode project using SwiftUI. In future installements of the series, I intend to at least discuss calling functions with idiomatic Haskell types with Swift ones (both with and without marshaling), SwiftUI observation, and iOS development which requires GHC to produce code for the iOS compilation target. At the time of writing I'm using XCode 15, Cabal 3.10, and GHC 9.8. There will be some features I use that are only available in these recent versions, however, the general idea of interoperability between Haskell and Swift stands on its own regardless - the now 7 year old swift-haskell-tutorial is still similarly relevant and greatly informed my approach, despite the end result being considerably different. The end goal is to create a multi-(apple)-platform application whose UI is programmed in Swift using SwiftUI while the data and logic of the application is implemented in Haskell which is called from Swift. The series of blog posts is further accompanied by a github repository where each commit matches a step of this tutorial. If in doubt regarding any step, simply checking the matching commit for absolute confidence you are understanding the practical step correctly. Visit this link to the haskell-x-swift-project-steps repository! Furthermore, I'm writing a build tool that will facilitate setting up and building a project like this without having to go through all the manual steps: haskell-swift. This write-up has been cross-posted to Well-Typed's Blog. 1 Hello, Swift, i ## Accelerate iOS Development Using Deep Links DevFeed: [Accelerate iOS Development Using Deep Links]() Original publisher: [Read original article]() Author: Doximity Published: 2023-03-13T09:18:00Z Content type: tutorial Language: en Sources: [Doximity]() Topics: [Development](), [iOS](), [Mobile](), [simulator](), [App]() Tags: [debug](), [demo](), [guide](), [guides](), [how-to](), [ios-development](), [simulator](), [ui]() ### AI overview This tutorial explains how to use Alfred workflows to organize deep links and launch them on running iOS simulators. It uses Apple Maps Guides as an example and shows how the workflow can document deep links, select one, and choose a simulator. ### Source excerpt Do you work on a large app with lots of deep links and dynamic content? This article will show you how to manage and leverage those deep links so you can spend more time coding and less time navigating the app. Here on the News team at Doximity, we have lots of content to manage, including articles, comments, and collections of articles. The problem compounds when considering that articles have a lot of different variations, and some of those variations are uncommon. The variety can make it hard to test the entire app, and a real pain when trying to debug a problem on a specific piece of content. Fortunately, most of that content is accessible via a deep link with the correct IDs. Unfortunately, that often means keeping a list of links in a notes document or sending a link to yourself in Slack. It's even worse when using the simulator since you cannot access those tools easily. That's where Alfred comes in. Alfred is an application launcher and productivity application that includes a rich set of tools for creating custom workflows. An Alfred workflow can organize deep links and launch them on any running simulator. Let's use Apple Maps as an example, as it's available on all simulators and supports deep linking to Guides. (Provided by Apple, Guides are curated collections of related points of interest. They can be accessed with a deeplink in the format maps://?pg=). Apple Maps has many Guides with different combinations of features to test. Finding a particular guide using the in-app search can take a lot of time. The Alfred workflow becomes both documentation of the various guides and a fast way to navigate to them. In the demo below, a hotkey triggers the workflow. Note that the workflow prompts to select a simulator when there are multiple running. The Alfred workflow consists of 4 work performing steps and some glue. The image below shows the Alfred workflow (which can be downloaded at the bottom of this article). The green steps cover selecting the d ## Исследуем баг iOS с помощью Hopper DevFeed: [Исследуем баг iOS с помощью Hopper]() Original publisher: [Read original article]() Author: WisDooMer (Badoo) Published: 2020-05-28T11:03:02Z Content type: tutorial Language: ru Sources: [Badoo EN](), [Badoo RU]() Topics: [iOS](), [Hopper]() Tags: [apple](), [badoo](), [hopper](), [ios](), [ios-92ecabba3495](), [ios-development](), [tag-8ecb3d630e31]() ### AI overview An iOS developer from Badoo investigates why telephone-number predictive keyboard suggestions disappeared in iOS 13. The article traces the issue to a keyboard implementation refactor and demonstrates restoring the suggestions in a test project using method swizzling. ### Source excerpt Привет! Меня зовут Александр Никишин, я занимаюсь разработкой iOS-приложений в компании Badoo. В статье я расскажу о том, как мы исследовали баг в UIKit, который Apple не хотела исправлять на протяжении полугода. Всё началось в августе 2019 года с первых бета-версий iOS 13. Тогда мы впервые столкнулись с проблемой. В приложениях Badoo и Bumble мы постоянно работаем над улучшением интерфейсов и, например, стараемся максимально оптимизировать нудный и не любимый пользователями процесс регистрации. Системные предиктивные подсказки над клавиатурой -- отличный способ сокращения количества кликов пользователя при вводе данных. Однако в новой версии iOS мы с удивлением обнаружили, что подсказки при вводе номера телефона пропали. Читать дальше -> ## Managing Massive View Controllers in iOS MVC Applications DevFeed: [Managing Massive View Controllers in iOS MVC Applications]() Original publisher: [Read original article]() Published: 2020-02-20T18:00:00Z Content type: opinion Language: en Sources: [Rambo Codes]() Topics: [mvc](), [iOS](), [iOS development](), [SwiftUI](), [Testing]() Tags: [app-architecture](), [apple](), [ios](), [ios-development](), [mvc](), [swiftui](), [testing](), [unit-tests]() ### AI overview The article discusses problems that arise when iOS MVC applications develop massive view controllers, tightly coupled screens, and difficult-to-write unit tests. It considers how to split view controllers while supporting older iOS versions and UIKit alongside SwiftUI. ### Source excerpt Gui Rambo writes about his coding and reverse engineering adventures. ## SwiftUI's iOS 13 requirement creates adoption and fragmentation challenges DevFeed: [SwiftUI's iOS 13 requirement creates adoption and fragmentation challenges]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2019-06-13T07:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [iOS development](), [SwiftUI](), [iOS](), [Android](), [ui](), [Jetpack]() Tags: [android](), [android-jetpack](), [fragmentation](), [ios](), [ios-development](), [jetpack](), [swiftui](), [ui]() ### AI overview The article argues that SwiftUI's requirement for iOS 13 creates a lengthy adoption lag and limits support for older iPhones, producing short-term challenges for iOS developers. It compares this with Android's historical fragmentation and discusses Jetpack's backward-compatibility approach. ### Source excerpt I've been dipping my toes into some iOS development recently. Nothing too crazy, just pairing with some colleagues and trying to see how we can jointly improve the technical design on both platforms .1 It so happens that Apple just finished it's annual conference WWDC, so I've been following the announcements closer this timer around. In that process, I ran across a tweet (from Jeff Nadeau who's a developer working at Apple): Sort of blown away by the take that a min OS target is harmful to a new framework. It's absurdly small-minded; one or two years of adoption lag is nothing when the arc of such a system is measured in decades. To set a little more context: the system Jeff talks about here is SwiftUi, a new framework library that will truly change the way iOS developers write their UI code. The niggle here is that SwiftUI is limited to just adopters of iOS 13. This basically means: Since the adoption rate for new OS updates is about 2 years for iOS, iOS 13 (newest version) will take 2 years to roll out to most iPhones iPhones 6 and below will never be able to run apps built with SwiftUi (as iOS 13 will run on iPhone 6S and later only) I found this bizarrely familiar since this was the exact same problem Google had with Android2 for the longest time. It was frustrating for Android developers because we would come back all excited from Google I/O, only to have the winds promptly taken out of our sails after we reviewed the horrendous state of OS adoption. It would be pretty irresponsible to start using SwiftUi right now for app developers building apps today. I do want to make it clear: this is not what Jeff is saying. He's not suggesting everyone start using SwiftUi right now. The latter part of the tweet clarifies this: ... when the arc of such a system is measured in decades 2 years might just be the cost to pay for iOS developers to have an amazing framework like SwiftUi that will eventually make development cycles 4x better. Especially since a sea of change is m ## Android Development Through the Eyes of an iOS Developer DevFeed: [Android Development Through the Eyes of an iOS Developer]() Original publisher: [Read original article]() Author: Keegan Rush Published: 2017-03-16T00:00:00Z Content type: opinion Language: en Sources: [The Coded Self]() Topics: [Android](), [Mobile](), [iOS](), [Android Studio](), [Development](), [Xcode](), [Objective-C]() Tags: [android](), [android-development](), [android-studio](), [developer](), [ios](), [ios-development](), [refactoring](), [xcode]() ### AI overview An iOS developer shares initial, explicitly opinion-based observations from trying Android development. The comparison covers Android Studio versus Xcode, Activities versus view controllers, device and screen-size fragmentation, version support, and XML-based localization. ### Source excerpt I've recently dipped my toes into Android development to see the differences in environment and tooling as compared to iOS development. While I haven't done much as of yet, I hope to ship some Android apps in the future alongside some iOS ones. I figured it was time to understand the platform so that I can better relate to the woes of Android development. Disclaimer Note that this is entirely opinion based, and these are only initial opinions. Understanding of any language or SDK fleshes out over time, and I'm looking forward to see how my understanding and opinions change as I write more and more Android code. The Findings I expected to see much more boilerplate and repetitive code as opposed to iOS, where we have the ability for frameworks to be more powerful and simple at the same time by tapping into the Objective-C runtime. While this was true to some extent, I'd like to talk more about some of the other differences I noticed: IDE If you're ever used a Jetbrains IDE or plugin, you'll love Android Studio. It's such a pleasure having the platform's standard IDE being one by Jetbrains. I've been burned by Xcode too many times, namely due to bugs and lack of refactoring tools, and I for one am quite pleased with Android Studio. Activities vs ViewControllers Where you'd use a UIViewController in iOS, you're using Activities in Android. While passing data through Intents is not perfect in my eyes, I prefer it to using the prepareForSegue method on iOS to see if the segue identifier matches the one you expect and then configuring the destination view controller. However, if you don't need to pass data around, I must say that handling all your segues in a Storyboard without writing any code is very convenient. Supporting different platforms and devices I'm starting to see that we have it so easy on iOS when it comes to supporting other devices. There's an almost unlimited number of hardware and screen size combinations for Android. Many iOS developers can name almost e ## Reducing the pain of git bisect with Xcode DevFeed: [Reducing the pain of git bisect with Xcode]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2017-01-22T11:49:01Z Content type: tutorial Language: en Sources: [Miguel Quinones]() Topics: [Git](), [Xcode](), [iOS](), [debugging](), [Mobile]() Tags: [bug](), [debugging](), [dependencies](), [git](), [ios](), [ios-development](), [xcode]() ### AI overview This article explains how Git bisect can identify regressions by performing a binary search through repository history. It focuses on reducing the friction of using bisect in iOS projects with CocoaPods and Xcode, including dependency installation, manual reproduction, device testing, app reinstallation, and repeated Xcode indexing. It begins describing automation that closes Xcode, updates dependencies, and reopens Xcode after each bisect step. ### Source excerpt There's times when you need to investigate regressions in your project, and you don't know have any clue as why something is happening. Git bisect is the best tool for this cases, but it can be painful to use in non small projects using CocoaPods and Xcode. I want to share what I've been doing to ease the pain. If you never used Git bisect, check this introduction. The git command performs a binary search across your repository history, starting from two known commits you provide to the algorithm: 'Good' and 'Bad'. 'Bad' will usually be your last commit, and 'Good' will be a commit back in the history of your repository, when you know the code was working as expected. For every step of the search you need to tell git if a commit is good or bad, either manually or automatically by running a script. Pain points When we enter the realm of iOS development, there's a some factors that make bisect tedious to use. If you use CocoaPods, and if you don't check in the 'Pods' directory in source control, every time you change branch or bisect selects a new commit, you might need to run pod install in order to have all dependencies available and compile correctly. If you are searching for a regression, chances are you don't have an automated test suite, so you'll need to run your app manually and reproduce the issue you are searching for. There will be cases when you're dealing with a bug that needs an app reinstall or needs to run on device to reproduce. To top all this, Xcode will start the long indexing process every time there's changes to the sources due to change of commit, so your computer will start doing lot of work. All of these nuances makes the process of searching for issues using bisect very tedious and not so 'magical' as it is supposed to be. I've nevertheless used bisect many times to save time otherwise wasted reading code and navigating breakpoints during long debugging sessions. You just need some patience and the will to automate some stuff. Reducing the pa ## The Monkey and the Apple DevFeed: [The Monkey and the Apple]() Original publisher: [Read original article]() Author: Steve Yegge (noreply@blogger.com) Published: 2016-11-17T07:11:00Z Content type: opinion Language: en Sources: [Steve Yegge]() Topics: [Mobile](), [Cloud](), [iOS development](), [Open Source](), [Google]() Tags: [cloud](), [google](), [ios-development](), [mobile](), [open-source]() ### AI overview The author describes turning an older game into a mobile MMORPG with a cloud backend. The project required substantial work involving cloud development, iOS APIs, and open-source technologies, and was opened for beta testing on supported iOS devices. ### Source excerpt It's been a while! I took a couple of years off blogging because I felt I didn't have much left in the way of interesting things to say. So I've been just been programming, and studying, and learning this and that. I've been doing a bit of Cloud development, and I taught myself iOS development, and after years in the Google cocoon I poked my head out and learned how people do things in the real world with open source technologies. And lo at long last, after some five years of tinkering, I finally have something kind of interesting to share. I wrote a game! Well, to be more precise, I took an old game that I wrote, which I've perhaps mentioned once or twice before, and I turned it into a mobile game, with a Cloud backend. It has been waaaay more work than I expected. Starting with a more-or-less working game, and tweaking it to work on Cloud and mobile -- I mean, come on, how hard can it be, really? Turns out, yeah, yep, very hard. Stupidly hard. Especially since out of brand loyalty I chose Google's cloud platform, which 3 or 4 years ago was pretty raw. And let's face it, iOS APIs have evolved a ton in that timeframe as well. So even as "recently" as 2013 I was working with some pretty immature technology stacks, all of which have come leaps and bounds since then. And now I have all sorts of stuff to share. Definitely enough for a series of blog posts. But I also have less time than before, because it's all happening in my non-copious spare time, all late nights and weekends. And running an MMORPG is a fearsome task in its own right. Incidentally, I've just opened the game up for beta testing. So if you want to try it out while you read along, visit http://ghosttrack.com to request an invite. (Edit, 12/13/16 -- BETA IS NOW CLOSED.) You'll need an iPhone, iPad, or iPod running iOS 10.2 (Edit: 9.2!) or later. I'd love to do Android and PC, but there's only one of me. For now. So where do I start? I guess the logical thing to do would be to start at the beginning, but [Next page]()