标签：#Mobile

Xiaomi is the latest manufacturer to release a short, wide foldable phone, in the same week Apple is expected to do the same. I got to try the 18 Fold behind closed doors at IFA last week, and while it looks and feels similar enough to Samsung's Galaxy Z Fold 8, superior specs make it […]

The build process for iOS applications involves multiple technical stages, including source code compilation, resource packaging, code signing, and IPA generation. Xcode is the first choice for most iOS developers, but build tools are not limited to Xcode alone; choosing the right tool for different development scenarios can significantly improve efficiency. xcodebuild: The Command-Line Version of Xcode xcodebuild is a command-line build tool bundled with Xcode that compiles and packages without opening Xcode. Common commands include: xcodebuild build to build the project, xcodebuild archive to create an Archive, and xcodebuild -exportArchive to export an IPA. xcodebuild is suitable for integration into CI/CD. CI/CD platforms such as Jenkins, GitHub Actions, and GitLab CI can invoke xcodebuild to perform automated builds. Its downside is that there are many parameters, with over a dozen common parameter combinations, requiring time for initial configuration. Moreover, xcodebuild depends on the Xcode environment and can only be used when Xcode is installed on a Mac. Fastlane: An Automated Build Tool Fastlane, written in Ruby, is an automation toolchain built on top of xcodebuild. It defines the workflows for building, testing, signing, and releasing through a Fastfile configuration file. For instance, lane :release defines a release pipeline that executes operations such as incrementing the version number, compiling, packaging, and uploading to TestFlight in sequence. Fastlane's match feature manages certificates and provisioning profiles, solving the problem of certificate synchronization in team collaboration. gym encapsulates the complex parameters of xcodebuild, allowing an IPA to be generated with a single command. Fastlane also has a rich plugin ecosystem covering push notifications, screenshots, and metadata management. Project Management with CocoaPods and XcodeGen CocoaPods handles the integration of third-party dependencies. Declare the dependent libraries

China is getting first crack at a British technology that might change how mobile games are made and played. Today, the Xiaomi 18 Fold launches in mainland China with an Arm Mali G2-Ultra NX graphics processor inside its custom Xring O3 chip. What's so special about that? After five years of development, Arm now has […]

Shooting mechanics are deceptively simple to prototype and shockingly hard to make feel good . Any developer can spawn a projectile and check for collisions in an afternoon. But the difference between a shooting game that feels floaty and forgettable versus one that feels punchy, satisfying, and addictive comes down to a handful of technical decisions most tutorials skip entirely: hit detection precision, feedback timing, physics tuning, and performance discipline on low-end devices. In this article, I want to walk through the core systems that go into building a mobile shooting game — using a piñata-style target shooter as the working example, since this sub-genre is a great teaching tool. It combines projectile mechanics, physics-based destruction, particle feedback, and score systems into a compact, easy-to-reason-about package. Whether you're building this exact genre or a completely different shooter, the underlying systems are transferable. Why Target-Shooting Games Are a Great Case Study Before diving into code-level concerns, it's worth understanding why this genre specifically is such a useful learning framework for Unity developers. A piñata-shooting mechanic strips a shooter down to its purest form: aim, fire, hit, reward. There's no complex inventory system, no enemy AI pathfinding, no multiplayer netcode to worry about. That simplicity makes it the perfect sandbox for really nailing the fundamentals — projectile physics, collision precision, and juicy feedback — without getting distracted by unrelated systems. At the same time, it's not trivially simple. To make a target-shooter feel good, you still need to solve: Consistent, fair hit detection across different screen sizes and aspect ratios Physics-based destruction that looks satisfying without tanking frame rate Particle and reward feedback that reinforces every successful hit Difficulty scaling through target size, movement, and timing Performance optimization so the game runs smoothly even on budge

TL;DR Every mobile app is forms underneath: signup, checkout, onboarding, KYC. The UI is an afternoon; the invisible stack (keyboard geometry, validation, migrations, RLS, typed writes) is where weeks disappear. Most AI form builders generate a pretty <TextInput> and stop. The useful pattern is generating the whole pipeline from one prompt: SQL migration, RLS policies, regenerated types, controlled state, visible errors, and a real Supabase insert. Five silent-failure patterns ship broken forms constantly: Alert.alert on web, unchecked { error } , RLS with no policy, stale generated types, and guard clauses that swallow crashes. Iterate additively (point-and-edit, follow-up prompts) instead of regenerating. Full regenerations lose per-field polish. Why "just add a form" is never just a form Ask any React Native developer what's slow about mobile development and forms will be near the top of the list. Not for the reasons the UI suggests. The visible part (labels, inputs, a submit button) is an afternoon. The invisible part is where the calendar goes: Keyboard geometry. iOS pushes content up; Android resizes; the submit button ends up under the keyboard on one platform and floats wrong on the other. Every screen with a TextInput needs a KeyboardAvoidingView with the correct behavior prop and a ScrollView with keyboardShouldPersistTaps="handled" , or it ships broken. Controlled state. Every field wants a useState slice, an onChangeText handler, a value prop, and a clean way to reset. Formik and react-hook-form abstract this, but they add a dependency graph, and neither handles the mobile-specific ergonomics. Validation with visible errors. A validator that fails silently is worse than none. Errors have to render on the correct field, at the correct time. The database half. A form that doesn't persist is a demo. Persisting means a table, columns of the right type, RLS policies (or every query returns zero rows with no error), a typed client, and error handling on the mu

Huawei has released its third trifold phone in China, and the company has clearly had half an eye on Samsung during development. Not only does the Mate XT 2 adopt the inward-folding form factor used on Samsung's Galaxy Z TriFold, it's also the first foldable to include a privacy-enhancing display, much like the one Samsung […]

Android App Protection Shouldn't Come at the Cost of Performance: The Lightweight Approach of XopProtector Android application protection has always involved a difficult trade-off. Stronger protection often means: Larger APK size Longer protection/build time Higher runtime overhead Slower application startup For large Android applications, these costs can become especially noticeable. XopProtector takes a different approach: strong protection with a focus on build efficiency, small APK overhead, and fast runtime startup. 300MB APK Protection in Under 5 Minutes For large Android projects, protection time is an important part of the development workflow. If protecting a 300MB APK takes 10–20 minutes or longer, it can significantly slow down: CI/CD pipelines Regression testing Beta releases Production builds Daily development XopProtector is designed to minimize unnecessary processing and optimize the protection pipeline for DEX, native libraries, and protected runtime data. In our testing environment, a 300MB-class APK can be protected within 5 minutes . This makes APK protection much more practical for frequent builds and automated CI/CD workflows. Actual protection time depends on hardware, APK structure, number of DEX files, native libraries, and the selected protection configuration. Small APK Size Overhead Protection should not mean dramatically increasing the APK size. Some protection solutions introduce significant additional runtime components or duplicated protected data, which can result in noticeable APK growth. XopProtector focuses on keeping the protection runtime lightweight and minimizing unnecessary additional data. The goal is simple: Original APK ↓ XopProtector ↓ Protected APK Protection ↑ Security ↑ APK overhead ↓ Build time ↓ Runtime overhead ↓ For large applications, keeping the size overhead low can be just as important as the protection itself. Fast Startup After Protection Build time is only one part of the equation. What users ultimately exper

The codebase survey was blunt: zero i18n infrastructure , roughly 660 user-facing text nodes across 53 files, a dozen alert dialogs, forty toasts, screen titles scattered across layout files. English was load-bearing everywhere. The reason to fix it then , rather than "after launch", was the closed-test window : Google Play makes you sit in testing for fourteen days regardless, and fourteen days of real people using translated builds is worth more than fourteen days of them using English. So the app learned six languages in one pass, then thirteen more. TL;DR — i18next + react-i18next + a plural-rules polyfill (the JS engine ships a stub Intl on some platforms, and Arabic needs six plural categories), eight namespaces, static resources so the first frame already has copy. Language is per-user, not per-device — the currency pattern — cached for the first frame, mirrored on the profile so it roams, cleared and restored on account switch; the Cognito locale attribute is written at sign-up so emails can follow later. Arabic flips the shell RTL with a native flag and a one-shot restart prompt, logical direction classes, and a font trick: the Arabic face is registered under the Latin font's names , so every existing style re-faces with zero call-site changes. Two tiers — six human-reviewable launch languages, thirteen machine-translated — generated by a diff-only pipeline that forces structured output because free-form JSON kept breaking on quotes. (Part 33 of Building CannyCart , a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.) Four pillars, all cloned from patterns the app already had The plan's insight was that the app already contained every pattern i18n needed — a per-user preference (currency), a device-detected onboarding step (country), a searchable picker (voice language). i18n was the fourth instance of each, not a new discipline. The library layer is i18next + react-i18next — pure JS, no dev-client rebuild — with t

The Fairphone 6 Plus feels like an extremely average midrange Android phone and I couldn't be more thrilled. The mission has always been admirable. Fairphone seeks out ethically sourced materials and offers a high degree of repairability for its devices. But the phones themselves required a lot of sacrifices, like putting up with underpowered processors […]

In December 2024, Google quietly updated its closed testing rules for personal developer Console accounts. For months, indie developers had to recruit at least 20 testers to keep their app opted in for 14 consecutive days before applying for production access. Under the revised guidelines, that threshold dropped from 20 to 12 testers. Understanding the nuances of the Google Play 20 testers vs 12 testers shift helps you plan your release schedule accurately without running into unexpected delays during Google Play Console verification. While lowering the number by eight testers sounds like a major relief, the core requirements behind closed testing have not changed. Google still enforces a strict 14 consecutive day duration, and the Play Console continues to monitor tester retention and engagement. A lower numerical requirement means less logistical hassle, but maintaining a stable group of committed testers remains the primary hurdle for independent developers. The Policy Shift: From 20 to 12 Testers Google originally introduced mandatory closed testing in November 2023 to improve app quality and curb low-effort submissions on the Play Store. Initially, all new personal accounts registered on or after November 13, 2023, were required to run a closed test with at least 20 opted-in testers for 14 days without interruption. After roughly a year of developer feedback regarding how difficult it was for solo creators to find 20 reliable participants, Google reduced the requirement to 12 testers in December 2024. It is crucial to understand who this rule applies to. The requirement exclusively targets personal developer accounts created on or after November 13, 2023. If you operate an organization or business developer account, or if your personal account was registered before November 13, 2023, you are currently exempt from this mandatory closed testing gate. However, if you fall under the new personal account category, reaching 12 continuous opt-ins is a strict prerequis

I Built a Mobile Terminal Around My herdr + Codex Workflow I am building Termish , an open-source mobile remote-work tool for SSH/Mosh terminals, file management, remote screens, and AI-assisted development. The unusual part is that I built much of Termish through Termish itself. My daily workflow is: Termish on my phone → herdr on my host → Codex in the project The development environment and AI tools run on my own machine. My phone is where I enter commands, describe tasks, upload screenshots, inspect changes, and check the resulting UI. Termish is both the product I am building and a tool I use to build it. Put remote work in your pocket. Source code: github.com/ttermish/termish Why do AI-assisted coding on a phone? A phone is not a replacement for a desktop machine. Its screen is smaller. Reading a large codebase is harder. Long debugging sessions are more comfortable on a larger display. Those limitations are real. But AI-assisted development changes part of the workflow. Many tasks become: Describe a requirement. Provide context. Let an agent make changes. Review the output. Run a command or test. Decide what to change next. Some of that loop works well on a phone. For example, when I think of a feature away from my desk, I can open the project and ask an agent to start implementing it. When I find a UI problem, I can upload a screenshot to the host and ask the agent to inspect it together with the code. After the change is done, I can review the diff, run tests, and check the actual UI through a remote screen. The goal is not to write an entire application on a phone. The goal is to make a phone a useful place to start work, inspect work, and keep a task moving. Why another SSH and AI coding tool? This is a fair question. Tools such as Termius and Blink already provide strong SSH, Mosh, and file-management experiences. If you already have a setup that works well, you can run Codex, Claude Code, or other agents through a terminal today. Happy and similar produ

When adb devices does not show the result you expect, reinstalling random drivers is rarely the best first move. The output already tells you which layer is failing. This checklist separates the most common states: device unauthorized offline An empty device list ADB not recognized by the terminal The goal is to diagnose the connection in a logical order: tool, cable, USB mode, authorization, and finally drivers. Before troubleshooting Make sure the basic setup is correct: Install the latest Android SDK Platform-Tools from Google. Use a USB cable that supports data, not only charging. Unlock the Android phone. Enable Developer options and USB debugging. Connect directly to the computer when possible instead of using an unpowered hub. The location of Developer options differs between Samsung, Xiaomi, Pixel, Huawei, OnePlus, and other interfaces. If you need the device-specific menu paths, this guide to enabling USB debugging on Android phones covers the common manufacturers and the RSA authorization step. Start with one command Open Terminal, PowerShell, or Command Prompt inside the Platform-Tools folder and run: adb devices For extra information, use: adb devices -l A normal result looks similar to this: List of devices attached R58M123ABCD device product:example model:Example device:example The word after the serial number is the important part. What each ADB state means Result Meaning Where to look first device ADB can communicate with the phone The connection is ready unauthorized The phone has not authorized this computer Phone screen and RSA prompt offline ADB sees the device but cannot communicate reliably ADB server, cable, port, or device Empty list The computer is not exposing the phone to ADB Cable, USB mode, driver, or debugging setting adb not recognized The shell cannot find the ADB executable Platform-Tools folder or PATH Case 1: The result is device This is the success state. ADB can send commands to the phone. You can test the connection with a harml

Under-the-hood breakdown of Huawei’s “Pure HarmonyOS” SDK for engineers and architects. For the past decade, mobile operating system architecture has been dominated by two paradigms: Android’s JVM-based, garbage-collected model, and iOS’s Darwin/Mach kernel with Swift/Objective-C. Huawei’s HarmonyOS NEXT introduces a third path. Often referred to as “Pure HarmonyOS,” this iteration completely drops AOSP (Android Open Source Project) compatibility. It is a microkernel-based, distributed operating system built from the ground up around a custom AOT compiler and a declarative UI framework. If you are a senior engineer or architect, looking at the HarmonyOS SDK can feel disorienting. The terminology shifts from Activities to UIAbilities, from ViewGroups to ArkUI, and from Java/Kotlin to ArkTS. To truly master this ecosystem, we must strip away the IDE abstractions and marketing terminology. Let’s reconstruct the HarmonyOS NEXT SDK from the silicon up — the Feynman way — to understand exactly how the machine breathes. The Core Engine: How Does HarmonyOS Execute Code Without a JVM? Press enter or click to view image in full size Android translates Java/Kotlin into Dalvik bytecode, which runs on the Android Runtime (ART) virtual machine atop a Linux kernel. HarmonyOS NEXT takes a fundamentally different path, utilizing the ArkCompiler and the Ark Runtime. JavaScript and TypeScript are dynamically typed. A virtual machine spends massive amounts of CPU cycle time inferring types and managing garbage collection. This overhead is unacceptable for a high-performance OS UI layer. ArkTS is a strict subset of TypeScript. It explicitly bans any , dynamic property addition, and eval . Why? Because the ArkCompiler is an AOT (Ahead-of-Time) compiler. When you trigger a build in DevEco Studio: 1.The ArkTS code is statically parsed. 2.Because the compiler possesses absolute type certainty (due to strict typing), it translates ArkTS directly into C/C++ data structures. 3.These structures

I shipped eight card and casino games to my portfolio in a single commit — solitaire, roulette, video poker, slots, baccarat, keno, war, higher-lower. All client-side Flutter web, all free, all deployed to Firebase Hosting in one push. flutter analyze was clean. I read the diff twice. The build succeeded. I deployed. Then I opened /games/roulette on the live site and got a page with a header, a subtitle, a bankroll readout, a spin button — and a completely blank rectangle where the betting board should have been. No red error screen. No console exception. No 404. Just an empty region the size of the thing that was supposed to be there, on a page where everything else rendered perfectly. The cause was one enum value: CrossAxisAlignment.stretch on a Row that, four widgets up the tree, was sitting inside a scroll view. In debug that combination throws a loud, well-written framework error. In release the assertion that produces that error doesn't exist, so nothing throws at all — the framework computes with infinity and paints nothing. A layout contract violation is not a type error, and no amount of static analysis is going to find it for you. This post is that bug in full, the family of unbounded-constraint traps it belongs to, why debug builds give you a false sense of safety, and the verification discipline I now refuse to skip. Eight games shipped, one board rendered nothing The symptom is worth describing precisely, because it's what makes this class of bug so slow to diagnose. The route loaded. The page scaffold — nav, page header, back link, related-games strip — was all there and correct. Analytics fired the pageview. The bankroll, the chip selector and the spin control rendered. Only the number grid, the largest single widget on the page, drew nothing at all. The space it occupied wasn't even collapsed to zero; it was just empty. The browser console was clean. Not "clean apart from a warning" — genuinely empty. Chrome DevTools' Elements panel showed what it al

Cast your mind back a decade or so, and smartphone makers were obsessed with shrinking the bezel on phones. Screens got bigger, the black bars around them got smaller, and for a while it looked like truly edge-to-edge displays were imminent. Then, progress just stopped. The bezel shrunk down until it was a millimeter or […]

With the P80 Ultra, TCL's E Ink-esque Nxtpaper phones are finally going OLED. Just like previous LCD models, the phone can switch to a low power, monochromatic display mode that replicates the look of paper when you want to read or minimize distractions. Only now you can switch back to what the company calls a […]

A couple of weeks ago, I helped a cross-platform app team with their App Store release. The code, packaging, and testing were all done, but we got stuck on the last step: how to get the IPA to the App Store. Nobody on the team had used a Mac, and many articles we read assumed you already have Xcode. That step is actually not that difficult. If you break down the complete iOS App Store publishing process, it comes down to registering an account, creating certificates, creating provisioning profiles, configuring Bundle IDs, packaging, uploading, and waiting for review. Each stage has clear steps, and I will walk through them in order below. Registering a Developer Account Registering a developer account is the first step. Both individual and company accounts cost $99 per year. To register, log in to the Apple Developer website with your Apple ID and agree to the agreement, and the account will be activated. Company accounts also require a D-U-N-S number. A free account can create development certificates and run internal testing, but it cannot submit or publish, and it cannot use capabilities such as Sign in with Apple, payments, or push notifications. To publish officially, you must upgrade to a paid account. Creating Certificates Certificates are the ticket for packaging and publishing. There are two types: development certificates (iOS App Development) and distribution certificates (iOS Distribution). The generated files are in P12 format. On a Mac, you would open Keychain Access and request a Certificate Signing Request file, then upload it to the developer portal. With Appuploader, a cross-platform team can generate certificates directly on Windows by entering a certificate name, email, and password, without touching the Keychain. The certificate can also be synced to different computers, saving considerable effort in team collaboration. Note that the certificate password must be remembered, because it is used as the private-key password for packaging and signing

I had been using Xcode for iOS development until one day I changed computers. Downloading Xcode took nearly two hours, and after unzipping, I found only 20GB left on the hard drive. Every major version update involved over ten gigabytes of downloads, plus Simulator and various iOS SDKs, so a 256GB Mac soon required cleaning up space. Later, a new teammate arrived with a Windows laptop and wanted to write iOS code, but the Mac configuration hadn't been approved yet. The threshold of iOS development being tied to Mac and Xcode is indeed not flexible for many scenarios. So I began to wonder: can iOS development be done without Xcode? Are there lighter alternatives? Several Alternative Paths Without Installing Xcode I first tried the approach of VS Code plus remote Mac compilation. Write code on Windows, connect to a remote Mac via SSH, and execute xcodebuild. The coding environment problem was solved, but the debugging phase is unavoidable—running on a real device requires Xcode to handle provisioning profiles and signing, so ultimately a Mac with full Xcode is still needed. Moreover, after each code change, the three steps of local editing, remote compilation, and syncing to the device made the workflow longer than developing directly in Xcode. I also tried the CI approach. Codemagic and GitHub Actions can automate build packaging, suitable for continuous integration before releases. However, frequent debugging and modifications during daily development—changing a line of code and running to see the result—cannot be pushed to CI every time and wait a few minutes. Its coverage is limited. I also considered AppCode, but it essentially still depends on Xcode's toolchain, and JetBrains has discontinued its maintenance. Another Approach: KXApp IDE KXApp has built the compilation toolchain into the IDE, allowing iOS applications to be compiled and signed without installing Xcode on the system. It uses VS Code as its editor layer, with shortcuts, interface layout, and plugin

Anyone who does iOS development has likely encountered this situation: after submitting your app with great effort, you receive an App Store review rejection email the next day with a variety of reasons—incorrect screenshot sizes, missing privacy policy links, unclear permission usage descriptions, and so on. Most rejection reasons can be avoided in advance, without waiting to be rejected before making changes. Here are the common reasons for rejection, categorized and explained with how to fix each. Screenshots and Metadata Issues Screenshots are a frequent cause of rejection. Rejections can result from sizes not conforming to App Store specifications, screenshots containing unreleased features, screenshots marked with test environment indicators (such as "beta" watermarks), screenshots inconsistent with the actual interface, or screenshots with incorrect device model labels. These issues can be caught by checking for yourself before submission. How to fix: Regenerate screenshots at the sizes required by App Store, with one set for 6.5 inches and another for 5.5 inches. If your app supports iPhone only, these two sets are sufficient; if it supports iPad, add an additional set. App Store screenshots do not support transparent backgrounds (alpha channel), so convert transparent backgrounds to opaque before uploading. When batch-uploading screenshots, tools like Appuploader allow you to select multiple images at once and upload them automatically sorted by device size, rather than dragging them one by one on the web page. Privacy Issues Missing privacy policy links or incomplete content is a common reason for rejection. If your app collects user data (including via third-party SDKs), you must provide a privacy policy, and the link must be accessible. How to fix: Prepare a privacy policy page and host it at an accessible URL, then fill in the link in the privacy policy section in App Store Connect. If your app involves third-party SDKs for advertising, analytics, payme

Google also announced a new visual assistant for Gemini Live and Keep integration with Messages.