# Snapp Mobile - Medium Snapp Mobile Engineering and Design Blog - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 2 of 3. DevFeed: [Ship It Right: A Swift Package Quality Checklist. Part 2 of 3.]() Original publisher: [Read original article]() Author: Oleksii Kolomiiets Published: 2026-01-05T08:49:32Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [Swift](), [Pull Request](), [GitHub](), [Development]() Tags: [community](), [contribute](), [documentation](), [github](), [open-source](), [pull-request](), [software-development](), [swift](), [swift-package-manager]() ### AI overview Part 2 of a three-part checklist for turning internal Swift packages into polished public repositories. It focuses on community and lifecycle practices, including contribution paths, simple pull request and issue templates, and contributor guidance. ### Source excerpt In Part 1, we built the foundation: documentation, tests, automated quality checks. Your Swift package is technically solid. The code works, it's well-documented, and it maintains consistent quality. Now comes the shift: from "my code works" to "others can contribute." Photo by Luca Bravo on UnsplashThis series is for Swift developers turning internal packages into polished public repositories. Part 1 covered documentation and quality. This part focuses on community and lifecycle. This is where many solo-developed projects stumble. The code is great, but there's no clear path for contributions. Issues pile up without organization. Releases happen chaotically. The infrastructure that worked for solo development doesn't scale to community development. The gap isn't technical -- it's process. You need infrastructure for guiding contributions, managing work, communicating changes, and shipping professional releases. The first time someone outside your organization contributes to your project is special. They took time to understand your code, fix something, and send it back. Make their experience smooth. A clear contribution path, simple templates, and responsive feedback turn one-time contributors into regular contributors. The infrastructure we're building isn't bureaucracy -- it's hospitality. It shows contributors that you value their time and want to make contributing easy.PR and Issue Templates: Keep Them Simple Here's my philosophy on templates: they should be easy and optional. PR templates with fifteen sections and required checkboxes don't increase quality -- they discourage contributions. Three sections are enough. I learned this watching pull requests to my own projects. Early on, I created comprehensive templates with sections for "Testing Strategy," "Performance Implications," "Breaking Changes," "Documentation Updates," and more. Nobody filled them out completely. Contributors would either skip most sections or write "N/A" repeatedly, which helped nobody. No ## 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 ## Multi-Module Projects with Cangjie DevFeed: [Multi-Module Projects with Cangjie]() Original publisher: [Read original article]() Author: Jasper Morgan Published: 2025-09-02T12:39:21Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [Package manager](), [modules](), [configuration](), [Code](), [Command-line interface]() Tags: [building](), [cangjie](), [cli](), [configuration](), [huawei](), [init](), [module](), [programming](), [run](), [structure]() ### AI overview A tutorial on using the Cangjie package manager, cjpm, to create and configure multi-module projects. It covers initializing a workspace, adding executable and library modules, registering them in the workspace configuration, adding source code, building, and running the project. ### Source excerpt The Cangjie package manager cjpm is a cli tool which can be used to setup multi-module projects. A module is simply a folder with a cjpm.toml file - whilst these can also be created by hand, the cli tool simplifies the process. The approach to the setup is to create a cjpm workspace at the project root and then separate module within the workspace. It will look like this: my-project (workspace) -- module-1 -- module-2 -- module-3Create the workspace In the root of your project, initialise a workspace: # create a project folder mkdir cat-pic-downloader cd cat-pic-downloader # initialise the workspace cjpm init --workspace At this stage, your project directory will have a cjpm.toml which is the configuration for your workspace. A newly initialised workspace config will look like this. [dependencies] [workspace] build-members = [] compile-option = "" link-option = "" members = [] target-dir = "" test-members = []Add the modules To add a module to the project, use the cjpm init command but with the options to specify the type of module to create (executable, a static library or a dynamic library). Let's add a couple of modules to our sample project. # create a static lib module called 'downloader' cjpm init --type=static --path downloader # create a static lib module called 'img-processor' cjpm init --type=static --path img_processor # create an executable module called 'runner' cjpm init --type=executable --path runner By default, a newly created module has a src directory and it's own cjpm.toml to configure the module. (Static library modules will have no source code. Executable modules will have a main.cj file.) Add the modules to the workspace So that the workspace is aware of the modules we created, we need to add them to the members field of the workspace's cjpm.toml. Edit the cjpm.toml as follows. [dependencies] [workspace] build-members = [] compile-option = "" link-option = "" members = ["./runner", "./downloader", "./img_processor"] target-dir = "" test-member ## Cangjie -- a programming language from Huawei DevFeed: [Cangjie -- a programming language from Huawei]() Original publisher: [Read original article]() Author: Jasper Morgan Published: 2025-08-19T07:37:53Z Content type: opinion Language: en Sources: [Snapp Mobile - Medium]() Topics: [Programming language](), [huawei](), [Programming](), [Code](), [Embedded Systems](), [Cross-Compilation](), [Mobile](), [cloud-computing](), [Package Management](), [debug](), [Testing](), [ide]() Tags: [architectures](), [bytecode](), [cangjie](), [china](), [cloud](), [cross-compilation](), [debugging](), [developers](), [development](), [embedded-systems](), [huawei](), [huawei-developers](), [language](), [mobile](), [package-management](), [programming](), [programming-language](), [programming-languages](), [tools]() ### AI overview This article examines Cangjie, an open-sourced programming language from Huawei. It describes Cangjie as a C-like language with features associated with Swift and Kotlin, support for embedded systems, mobile development, and cloud architectures, interoperability with C and Python, JVM bytecode compilation, cross-compilation, and integrated developer tools. The article suggests Huawei created it to gain more control over its language roadmap and consolidate development skills across products. ### Source excerpt Cangjie -- a programming language from Huawei Huawei have been busy. Last month they open-sourced a programming language that is looking pretty interesting. Whilst you might not be writing in Cangjie next week, it's good to see what one of the world's largest technology companies is doing such that they have created a new programming language. TL;DR Cangjie is a C-like programming language that feels more like Swift/Kotlin than Java/C# or JavaScript/Typescript. The idea is for Cangjie to become the common programming language to be used throughout Huawei. Cangjie can be used for embedded systems, mobile development, server-side cloud architectures. It supports a variety of programming paradigms (function, OO, procedural), compilation and integration options. Cangjie can call C libraries (and be called from C), use Python libraries and even compile to JVM bytecode. Cangjie supports language extension to create lightweight DSLs. Primarily Cangjie programs are compiled into machine code -- this include cross compilation which mean they can run natively on different computer architectures. Cangjie comes with a set of in-built tools for developers such as package management, debugging, testing and IDE integration. Cangjie is openly available since this month and is in version 0.53.13. Why create a new language? Simply put, Cangjie gives Huawei a level of control and an economy of scale that they cannot get from other languages. Most mainstream languages are driven predominantly by teams in USA and Europe. It is hard to influence the road map for these languages -- especially for those tightly controlled by corporations (e.g. Java/Kotlin/Swift). Furthermore, consolidating programming skills could be a big efficiency gain for Huawei -- engineers working on products ranging from routers to petabyte storage to cloud computing and mobile devices can coalesce around one language and toolset. Show me some code I won't go into any detail here so this is just to satisfy your curiosit ## Why Huawei's HarmonyOS Next could matter for small computing devices DevFeed: [Why Huawei's HarmonyOS Next could matter for small computing devices]() Original publisher: [Read original article]() Author: Jasper Morgan Published: 2025-04-03T08:46:50Z Content type: opinion Language: en Sources: [Snapp Mobile - Medium]() Topics: [Operating system](), [huawei](), [Open Source](), [Microcontrollers](), [Robotics]() Tags: [harmony-os](), [huawei](), [microcontrollers](), [mobile-app-development](), [open-source](), [operating-systems](), [os](), [robotics]() ### AI overview This opinion article examines Huawei's HarmonyOS Next, a version of HarmonyOS without Android support, and argues that an operating system designed for small computing devices could have a valuable role as those devices become more widespread. ### Source excerpt Last year Huawei ditched Android and in 2025 will be releasing more and more devices running its HarmonyOS Next software platform. HarmonyOS is based on an open source operating system (OpenHarmony) that started as an R&D project at Huawei in 2012. The operating system has been architected to support a wide array of small computing devices from microcontrollers to tablets. It is already used in several of Huawei's TVs, wearables and wireless router products. In 2024 a 'pure' version of the OS, without Android support, was released. This has been branded HarmonyOS Next. Several questions leap to mind: 1/ Does the world actually need a new OS? 2/ Why should we care about what Huawei is doing -- especially those of us outside China? 3/ Finally, what are the chances of success for a new OS? Let's look a little deeper into these topics and try to understand what's going on in this space. 1/ Does the world need a new OS? YES Let me explain why I have come to this conclusion. Computing needs have changed We have seen a steady growth of small form factor computing. We carry computing devices in our pockets, they are found in devices throughout our homes, they are part of our vehicles, they are in medical devices, and in countless industrial settings. Within this context, one could argue that phones are at the larger end of the spectrum when it comes to small computing devices. Single board computers and microcontrollers can be found in mechanical keyboards, security cameras, hand-held medical equipment, at the checkout in our shops etc. Going further, it's not a huge leap to see that the field of robotics is due to take off with the advent of AI for real time context-aware decision making. My first argument, therefore, is that an operating system specifically designed for small computing devices will have a valuable role to play. (Neither iOS nor Android were designed or have evolved to address this need.) Innovation and competition are good Several operating system innovati ## Meet SnappTheming DevFeed: [Meet SnappTheming]() Original publisher: [Read original article]() Author: Volodymyr Voiko Published: 2025-02-27T10:28:25Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [Swift](), [Library](), [Xcode](), [JSON](), [ui]() Tags: [design](), [getting-started](), [installation](), [ios](), [json](), [library](), [open-source](), [swift](), [swift-package](), [ui-components](), [xcode]() ### AI overview This tutorial introduces SnappTheming, an open-source Swift framework for dynamically applying app themes from JSON declarations. It explains how to add the package to an Xcode project and use theme elements such as colors, fonts, gradients, images, animations, metrics, and shapes in UI components. ### Source excerpt Today, most applications interact with cloud-based content. In addition to content, app configurations such as feature flags, translations, and even UI elements (Server Driven UI) are often managed from the server. But what about theming? How can we hotswap or update app themes without requiring app updates? I have the answer! Recently, we at snappmobile.io announced our open-source library, SnappTheming. This Swift framework simplifies the integration of dynamic design themes into your applications. By utilizing JSON declarations, SnappTheming facilitates the extraction and application of various theming elements, including colors, fonts, gradients, and shape styles, directly into the application's user interface. In this article, we will explore how to get started with the SnappTheming library, including installation steps and basic usage. Getting Started In this section, we will create a sample app that utilizes the SnappTheming dependency. We will define a theme and use its declaration to retrieve styling elements and apply them to various UI components. This will demonstrate how easy it is to implement dynamic theming in your application. To get started, first create a new project in Xcode. Creating the Project Before we begin, ensure that you have Xcode installed (make sure it's a version compatible with Swift). Follow these steps to create a new Xcode project: Open Xcode and select "Create a new Xcode project." Choose the appropriate template for your app, such as "Single View App." Fill in the necessary details like project name and organization identifier, then click "Next" to create the project. Adding the Framework Dependency Next, we need to add the SnappTheming package dependency to our project. Follow these steps: Open your project's settings and navigate to the "Swift Packages" tab. Click the "+" button to add a new package. Enter the URL for the SnappTheming repository and select the version you want to use. Click "Add Package" to include it in your ## Linting a Swift package with swift-format DevFeed: [Linting a Swift package with swift-format]() Original publisher: [Read original article]() Author: Oleksii Kolomiiets Published: 2025-01-27T08:59:47Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [Swift](), [Xcode 16](), [developer tooling](), [Development]() Tags: [build](), [development-tools](), [how-to](), [ios](), [lint](), [packages](), [plugin](), [swift](), [swift-package-manager](), [xcode-16]() ### AI overview This tutorial explains how to enable linting for a Swift package during its build process with the built-in swift-format tool included in the Xcode 16 toolchain. It covers creating a package, adding a package plugin, attaching the plugin to targets, and displaying a test warning during the build. ### Source excerpt Linting your code is handy and effective way to keep your team's code style in shape. Nowadays it's hard to imagine a project without functionality that alerts developers with warnings or errors about issues in the code. It could be done with a simple script added to build phases. But what can you do when you don't have one? Packages are excluded from this option, but they still need to be maintained. Or at the very least, you'll feel much better knowing your package code is clean and consistent, and no one can make it messy without receiving a warning. This article explains how to enable linting for a package during its build process, using only the built-in swift-format tool -- no external libraries required. Preparation With Xcode 16, swift-format is included as part of the Xcode toolchain, eliminating the need for external libraries and making Swift file formatting more convenient. For more information, refer to the Getting swift-format section. 1. Create a package Launch Xcode and select File > New > Package from the menu. Chose Library and add the name to the package. 2. Add Plugin Package plugin is: Swift script that can be run as part of your buildA package could have plugins as extra, or be all about pluginsPackage plugins are available only within packageGeneral plugins can be made available to the outsideLets you access development tools on your machine More information about package plugins can be found in the Meet Swift Package plugins article. Start by creating a dedicated folder for all potential plugins, including the one you're currently working on. Ctrl + click on your package name in Xcode and select "New Folder" or use any other method to create a folder in the root of your project. Next, create a folder specifically for your plugin's logic. Since it will lint the package code using swift-format , the name SwiftFormatPlugin was chosen. By the end, the structure would look like this Now, let's add some content to plugin file import Foundation impor ## HarmonyOS App Development 101 DevFeed: [HarmonyOS App Development 101]() Original publisher: [Read original article]() Author: Jasper Morgan Published: 2025-01-18T23:23:13Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [App](), [Development](), [ide](), [huawei](), [SDK](), [Tooling](), [jetbrains](), [Package Management](), [Testing](), [Open Source]() Tags: [android](), [app](), [app-development](), [apps](), [code-completion](), [debug](), [deployment](), [development](), [harmony-os](), [huawei](), [ide](), [jetbrains](), [open-source](), [package-management](), [programming-languages](), [refactoring](), [sdk](), [testing](), [tools](), [ui](), [ui-framework]() ### AI overview An overview of HarmonyOS Next app development, covering the Huawei-based DevEco Studio IDE, project configuration, SDK versions, modules, and common development features. The article also outlines programming languages, UI frameworks, build tools, package management, execution, debugging, testing, and profiling. ### Source excerpt Huawei have taken a big step in moving away from the Android platform with the launch of new devices running HarmonyOS Next. This is a brand new operating system that had been design specifically for devices. This means it is lightweight, supports a range of device types, is modular and extensible. In this article we aim to give you an overview of what is available to developers wishing to build apps on this new platform. To that end, we will be looking at the following topics: The IDE Programming Languages UI Framework Build Tools Package Management Running code (devices/emulators) Debugging Testing Profiling Other cool stuff If you are curious about the Harmony platform, its Open Source foundations (OpenHarmony) and its global reach (Oniro), we have written about it here. The IDE The development environment for Harmony apps is currently a Huawei-based IDE which is based on the JetBrains IDE platform. The good news is that JetBrains offers a world-class IDE platform and it makes for a very solid development experience for Harmony apps. For those, wanting to keep to the Open Source side of Harmony (OpenHarmony and Oniro), you are out of luck right now. DevEco Studio is proprietary, albeit free to use software. Let's look at a couple of IDE features -- these should not surprise you but hopefully demonstrates that the platform is already in a good place (as far as IDEs go). Project Creation Creating a project will look familiar already for many. There are a few project templates to choose from to bootstrap your project. New Project Templates You will also then need to configure a couple of options -- a couple of notes on these (which could probably be expanded into a separate article). Firstly, the bundle name is used for app signing and identity. Secondly, an app supports a single SDK version. (The latest SDK version is 13, however version 11 is still widely used.) Thirdly we can specify the module name. The default ('entry') isn't very descriptive. If you have a singl ## CI CD for OpenHarmony Project -- GitHub Action DevFeed: [CI CD for OpenHarmony Project -- GitHub Action]() Original publisher: [Read original article]() Author: Payam Zahedi Published: 2024-12-09T12:05:48Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [GitHub Actions](), [CI/CD](), [GitHub](), [Development]() Tags: [ark-ts](), [build](), [building](), [ci-cd](), [ci-cd-pipeline](), [ci-cd-workflows](), [github](), [github-action](), [github-actions](), [harmony-os](), [open-harmony](), [sdk](), [testing](), [verify]() ### AI overview This tutorial explains how to create a GitHub Actions CI/CD workflow for building and verifying an OpenHarmony application. It introduces the roles of DevEco Studio, Hvigor, OHPM, the OpenHarmony Code Linter, and the reusable oh-action for preparing the required SDK and command-line tools. ### Source excerpt CI CD for OpenHarmony Project -- GitHub Action When developing OpenHarmony, we typically use DevEco Studio to write our code, build the project, test it, and run it on our devices, with DevEco Studio taking care of everything under the hood. However, as engineers, we love to automate repetitive processes, right? This is where CI/CD workflows become incredibly useful. GitHub Actions, in particular, is a popular and highly customizable workflow solution. In this article, we'll explore how to create a workflow on GitHub Actions to build and verify our OpenHarmony application. A Little Context To write our GitHub Action workflow, we first need to understand how DevEco Studio works under the hood. Specifically, what tools does it install, and how are they used? In this article, we won't dive too deep into all OpenHarmony tools and DevEco Studio capabilities. Instead, we'll provide a brief overview to understand the components needed for our workflow. hvigorw Hvigor is a simple build tool, much like Gradle for Android, but designed specifically for OpenHarmony apps. It helps you manage tasks, dependencies, and builds easily. DevEco Studio uses hvigorw to build, test, and run apps on devices. ohpm OHPM (OpenHarmony Package Manager) is akin to npm for JavaScript, but tailored for OpenHarmony applications. It helps facilitate the publishing, installation, and management of dependencies for shared packages. DevEco Studio uses OHPM to manage third-party libraries within OpenHarmony projects. Code Linter OpenHarmony's Code Linter is a tool that checks ArkTS and TypeScript code for best practices and coding standards. It helps developers identify and fix issues during development, ensuring high-quality code. Now that we have a good understanding of the tools involved, the next step is to bring these components together into a cohesive GitHub Action that can automate our workflow. This is where oh-action steps in. GitHub - Snapp-Mobile/oh-action: The oh-action is a GitHub Action t