标签：#mobile

GrapheneOS, an open source version of Android that prioritizes security and privacy, has detailed its plans for supporting Motorola smartphones. Official support is set to arrive next year, starting with traditional flagships, before rolling out to Motorola's foldable phones and perhaps cheaper models, eventually. In a Mastodon thread, the GrapheneOS Foundation announced that it will […]

How to get a photo below a strict KB limit Many government portals, job forms, school applications, and support websites reject an otherwise valid photo because it is larger than a fixed limit such as 100 KB or 200 KB. Standard gallery apps usually offer cropping or a quality percentage, but they do not tell you whether the final file will meet a specific upload limit. That is the problem I built FormFit to solve on Android. Why exact-KB compression is tricky File size depends on more than width and height. Image detail, color variation, output format, and compression quality all affect the result. A quality setting that works for one photo may leave another photo far above the required size. FormFit works toward a maximum KB target and adjusts the generated copy for you. The practical goal is to create a file at or below the limit while keeping it as clear as possible. Compress a photo on Android Install FormFit from Google Play . Open the photo-compression tool and select the image you need to upload. Enter the maximum file size required by the website or form. Optionally resize the image dimensions or choose JPG, PNG, or WebP for the generated copy. Run the compression, review the result, and save or share the new file. The original photo is not replaced. FormFit creates a separate output copy, so you can compare the result before uploading it. Remove metadata from generated copies Photos can contain metadata such as device or capture information. When you only need to submit the visible image, FormFit can remove metadata from the generated copy. This does not change the original file. Turn several photos into one PDF Some forms ask for a single PDF instead of multiple image files. FormFit can combine up to 20 selected photos into one PDF directly on the phone. This is useful for receipts, scanned notes, application documents, and other small document sets. On-device processing The selected photos and PDFs are processed on the Android device. FormFit does not req

📚 This is part 2 of a series. Part 1: The Origin Story Part 2: [Current Article] Part 3: Coming soon... Let me tell you about the day my crash reporting UI crashed. The Grey Screen One afternoon, my Android app's crash screen rendered all-grey. No content. No report button. Just a blank slate where the app's last line of defense should have been. The root cause? A stale file from Gradle's build cache after a major refactor. The compiled resource IDs no longer matched the packaged resource table. ViewBinding inflated the wrong layout, and a silent NullPointerException killed the crash screen itself. It was invisible in CI. It only appeared in specific rebuild scenarios. And it took hours to trace. That bug taught me something important: The fix isn't done when the patch ships. It's done when the lesson becomes automated. So I wrote a build-time task that reads the compiled class files directly, compares them against the final packaged resources, and verifies every constant matches. It runs automatically after every packaging step. You never have to remember to invoke it. That was the first of many incident-driven tools I built. The FAB That Disappeared A few weeks later, a developer tools Floating Action Button vanished from consumer apps. Debug menus inaccessible. Secure screens incorrectly enabled. Turns out, my shared library's BuildConfigUtils was reading the library's own BuildConfig —which is baked as "release" at publish time. An AAR can never know the consumer's build type. 25 files across 34 call sites were silently broken. I built a Gradle plugin that generates a SskBuildConfig object per consumer module, per variant, using AGP's onVariants callback. It registers generated source via KotlinCompile.source() —not reflection, which broke across AGP versions. It detects Android plugins by extension type, not hardcoded IDs, so it works with com.android.application , com.android.library , com.android.dynamic-feature , and any future Google plugin. Same package as

It was the final ten minutes of a high-stakes client presentation. I was mid-sentence, explaining a complex system migration, when my phone erupted with a loud, aggressive ringtone. The room went silent, but my phone did not. I scrambled to silence it, accidentally hitting the volume buttons while fumbling with the screen. That moment of pure, unadulterated embarrassment followed me for days. It was not the first time this had happened, but it was the time I decided I had finally had enough of relying on my own memory to toggle sound profiles before entering sensitive environments. Most of us live in a state of perpetual concern regarding our devices. We walk into movie theaters, attend religious services, or sit through medical consultations, constantly checking our pockets to ensure we have toggled the mute switch. If we forget, we face the social friction of a disruption. The existing solutions were either too manual—requiring a conscious effort I rarely possessed in the moment—or too intrusive, demanding constant location permissions and draining the battery to perform simple state changes. I wanted something that functioned as a set-and-forget background utility. I needed a system that understood the context of my environment without requiring me to interact with an interface every time my routine shifted. To build this, I had to architect a background service that could survive the aggressive power-management constraints of modern Android, specifically Doze mode. The primary challenge was ensuring that my sound-toggling logic fired precisely when a rule was triggered, even if the device had been sitting idle for hours. I initially experimented with a standard Service , but Android’s lifecycle management quickly killed it to save resources. I shifted to using a ForegroundService with a persistent notification, which is the standard approach for long-running tasks, but that only solved the visibility part. The real hurdle was the timing accuracy required for eve

It happened during a quiet, solemn moment at a funeral. I felt the vibration in my pocket, and for a split second, I panicked. I had silenced my phone before entering, but I had accidentally toggled it back to normal mode while checking an email earlier that morning. In that room, the sound of a notification ping felt like a gunshot. The embarrassment was immediate and visceral. It was a clear signal that I needed a better way to manage my device's sound profile, a system that didn't rely on my flawed human memory. We live in an era of hyper-connectivity, yet our phones are surprisingly dumb when it comes to context awareness. I found myself constantly manually adjusting volume sliders. Meetings, gym sessions, prayer times, movie theaters—the list of places requiring silence is endless. Most existing solutions were either too heavy, requiring complex IFTTT integrations that lagged, or they were privacy-invasive, requiring constant cloud syncing. I wanted something that lived locally on my device, respected my data privacy, and didn't turn my phone into a brick by noon. The core problem wasn't just the silencing; it was the cognitive load of having to remember to revert those changes, which is how you end up missing important calls for the rest of the day. To build Muffle, I had to solve the geofencing puzzle. The temptation for any Android developer is to fire up a LocationRequest with high-accuracy settings and just poll the GPS coordinates. That is the fastest way to destroy battery life and get your app killed by the Android system's battery optimizations. Instead, I leaned into the GeofencingClient API. It is designed precisely for this use case: it lets the system handle the heavy lifting of location monitoring at the hardware level, rather than keeping the radio awake in my application process. I configured the GeofencingRequest using GEOFENCE_TRANSITION_ENTER and GEOFENCE_TRANSITION_EXIT triggers. The magic happens in the PendingIntent that gets fired when th

Pub.dev Package: Link GitHub Repository: Link Imagine getting into a serious car crash in a remote...

Yes, so long as you're willing to put in the work (and money) for better photos.

Short answer: model each SMS OTP as an auditable challenge that can be consumed once, and make the server—not the mobile screen—the authority for expiry, autofill acceptance, repeat-request limits, and recipient suppression. Those decisions belong in the security contract before a messaging adapter is selected. The concrete problem is deceptively small: a mobile user asks for a code, the app receives a text, and the user signs in. In production, the same endpoint is also a spending endpoint, a privacy boundary, and a fraud signal. A duplicate tap, a delayed carrier message, or a recycled phone number can turn a pleasant login flow into an account-enumeration or SMS-bombing incident. I approach this like a ledger. Every state transition needs an idempotency key, an audit record, and a clear owner. Seven invariants keep the design reviewable. Stop. Consent, retention, and privacy records The server creates a challenge with a random, short-lived code, stores only a salted hash, and binds the challenge to a normalized recipient plus a login intent. The client receives an opaque challenge identifier; it never decides whether a code is valid. Verification consumes the challenge atomically, so two concurrent requests cannot both win. A resend is a new delivery attempt on the same login intent, subject to a cooldown and a rolling budget. It must not silently invalidate a code that is already in transit unless the product explicitly documents that behavior. Suppression is checked before dispatch and again when delivery feedback is ingested. That second check matters for bounces, reassigned numbers, and manually blocked recipients. Option Strength Cost or boundary One service owns challenge and delivery state Simple audit trail and exactly-once verification Requires a durable store and transactional writes Separate identity and messaging services Teams can deploy independently Correlation IDs and replay rules cross a network boundary Client-generated code or expiry Fast proto

RayNeo's latest AR smart glasses are going for very different audiences: The very discrete, and the very nerdy.

An iOS app can feel slow even when its interface looks well-designed and responsive. The problem may not always be the UI or the code running on the device. Often, the real issues are hidden in network requests, API responses, WebSocket connections, and background activity. For developers, finding these problems requires visibility into what is happening behind the screen. This is where Owlse , a network inspection and debugging tool for iOS and macOS developers, can help. 1. What Actually Makes an iOS App Feel Slow? Several hidden network issues can affect an app's performance: Slow API responses Too many network requests Large data payloads Connection delays Failed or repeated requests Background network activity A user may simply see a loading screen or delayed response, while several network operations are happening in the background. Understanding these operations is the first step toward finding the actual cause of the problem. 2. Why Traditional Debugging Can Make These Issues Hard to Find Network-related problems are not always easy to identify through standard debugging. Developers may need to switch between different tools to inspect requests, analyze timing, investigate WebSockets, and understand application issues. When an app generates hundreds of requests, finding one problematic request can also take considerable time. Without a clear view of network activity, developers often have to rely on assumptions. A dedicated network debugging workflow can make this process much easier. 3. Meet Owlse: Network Debugging for iOS & macOS Owlse is built to give iOS and macOS developers greater visibility into their application's network activity. Instead of treating network behavior as something happening in the background, Owlse helps developers inspect and understand it. With features including live request streaming, request inspection, timing analysis, WebSocket inspection, mocking, crash reporting, search, HAR export, and timeline debugging, Owlse brings impo

The foldable phone market is in the middle of a huge transformation, but no one told Google. Last year, Samsung transformed its Galaxy Z Fold 7 with a dramatically thinner design. This year, it made its phones thinner and lighter again, almost eliminated the crease, and introduced a new passport-sized form factor that feels like […]

WhatsApp is testing Scam Alert in limited beta, using on device machine learning to detect potential scam messages from non contacts. Meta's architecture keeps message content on the device while using confidential computing, Oblivious HTTP, differential privacy, and model transparency to measure performance and protect model delivery. By Leela Kumili

The Fairphone 6 Plus is a minor hardware refresh, but a major launch for the company: It's the first phone that Fairphone is selling directly in the US. It's on sale now for $649.99, available through Fairphone's website and Amazon, and is sold unlocked with support for both T-Mobile and AT&T. In Europe, it costs […]

I’ve been building a side project called OopsCalorie , an AI-powered calorie and meal tracking app. The idea sounded simple enough: User logs or takes a photo of their food. AI identifies the meal. Estimate calories and macros. Save the entry. Done. Simple, right? Well... Then we started testing it with Filipino food. 😂 AI Meets Filipino Food 🇵🇭 One of the funniest parts of building OopsCalorie has been testing the food recognition. At one point, our AI confidently looked at dinuguan and decided: That's champorado. Okay. I can kind of see where you were coming from. Both are dark, both can be served in a bowl... But still. 😂 Then came bagnet . AI: Lumpiang Shanghai. Bro. Not even close. 😂 These bugs are funny, but they also exposed one of the more interesting engineering problems behind OopsCalorie: Image recognition is only the first step. Correctly identifying a meal — especially regional dishes — requires much more context than I initially expected. The Real Problem Isn't Just Calories When I started the project, I thought the difficult part would be estimating calories. Turns out, before you can estimate: You need to know what the food actually is. And food can be surprisingly ambiguous from an image. A photo might contain: multiple dishes sauces hiding ingredients visually similar foods regional dishes that aren't well represented in training data different cooking methods unknown portion sizes ingredients completely hidden underneath other ingredients Even humans sometimes need context. "Is that pork adobo or humba?" "Is that fried pork belly or bagnet?" Now imagine asking an AI to determine that from pixels alone. Building Around AI Instead of Blindly Trusting It This changed how I'm approaching the system. Instead of treating the AI response as absolute truth, OopsCalorie is evolving toward a workflow where AI provides an intelligent estimate while the user still has the ability to provide context and correct it. We're experimenting with things like: Image +

Like the pets of any self-respecting millennial, my cats have their own Instagram account. Noodle and Loaf - aka Carb Cats - aren't exactly celebrities. But they are used to having their photos taken a lot. Between their Instagram account, my regular need to test smartphone cameras, and the fact that they are two adorable […]

A team-lead's breakdown of 8 real React Native project architectures — what each one actually solves, where the "Domain-Driven" and "Micro-Frontend" labels get misused, and how to pick one without over-engineering an MVP. The house-building analogy When you build a house, the labor that lays the bricks gets paid well. The architect who drew the blueprint gets paid more — because the architect already accounted for the second floor you'll add next year, and made sure the foundation could take the load without anyone tearing down a wall later. React Native codebases work the same way. The folder structure you pick on day one either lets your app absorb 10 more features and 40 more engineers, or it collapses under its own weight and someone gets hired specifically to rewrite it. This is also, almost word for word, what a React Native team lead interview is probing for: "Walk me through how you'd structure a project" or "What's your folder structure and why?" Nobody wants your code in that answer — they want to hear you reason about trade-offs. So here are eight real folder structures, what each one actually solves, and two places where the common naming gets sloppy. 1. Flat Structure — for prototypes and MVPs src/ ├── App.js ├── HomeScreen.js ├── ProfileScreen.js ├── Button.js ├── Card.js └── api.js Everything in one src/ folder, no categorization. When to use it: a client demo, a hackathon build, a single-screen proof of concept — anything with a short shelf life, or code you expect a bigger team to re-architect later. Where it breaks: past 10–15 files you're scrolling through an undifferentiated pile with no signal about what belongs together. 2. Feature-Based Structure — the industry default src/ └── features/ ├── auth/ │ ├── components/ │ ├── screens/ │ └── services/ ├── profile/ │ ├── components/ │ ├── screens/ │ └── services/ └── feed/ ├── components/ ├── screens/ └── services/ This is the most common structure in production RN apps. Each product area — auth, pro

Cloud-based AI has two persistent problems for mobile developers: latency, because every inference call is a round trip to a server, and privacy, because user data has to leave the device to be processed. By 2026, Apple has shipped enough of a native stack that bypassing the cloud entirely — architecting genuinely autonomous agents that run inference, reasoning, and action selection directly on-device — has moved from a theoretical exercise to a practical, documented architecture pattern. Why Local-First Is the 2026 Competitive Edge The clearest signal of how seriously Apple is treating this shift arrived at WWDC 2026 with Core AI, a new OS-level framework built directly into Apple Silicon. Core AI allows developers to load, specialize, and run AI models entirely on-device — including local language models up to 70 billion parameters — with zero server dependency and zero token cost. Models are automatically specialized for the hardware they run on, with ahead-of-time compilation support for fast load times. That's a meaningfully different proposition than earlier on-device AI efforts: it's Apple positioning local inference as genuinely competitive with cloud-scale models, not just a lightweight fallback for when connectivity is poor. The Three-Piece Agent SDK As of 2026, Apple effectively ships three developer-facing pieces that together form something close to a full AI agent SDK. The Foundation Models framework handles on-device inference — direct, programmatic access to the same large language model that powers Apple Intelligence itself, running on the device's Neural Engine rather than through a wrapped cloud API. App Intents exposes an app's actual capabilities to that intelligence, acting as the action layer an agent can call into. Private Cloud Compute (PCC) handles the cases that genuinely exceed on-device capacity, providing a scale fallback rather than a default path. The on-device model handles reasoning, App Intents handles action, and PCC handles scale

1. What Is Android Developer Verification and Why Google Introduced It In August 2025, Google quietly announced a major policy change called Android Developer Verification . Starting September 2026 (first in select countries like Brazil, Indonesia, Singapore, and Thailand, then rolling out globally), every developer whose app is installed on certified Android devices must register with Google. This is not limited to apps distributed through the Google Play Store. It applies to all apps — including those sideloaded from websites, shared via APK files, distributed through F-Droid, or even internal company tools and hobby projects. Google’s official reason is “improved security and accountability” — to stop repeat malware developers. However, the implementation goes far beyond that. It creates a central registry controlled entirely by Google, where every person or organization building Android software must identify themselves. 2. How the Verification Process Actually Works (Step-by-Step Details) To get their apps installable on most Android phones, developers must complete the following: Create or use a Google Play Console developer account. Pay a registration fee (standard accounts are around $25, with possible additional costs). Agree to Google’s lengthy Terms and Conditions without negotiation. Submit government-issued identification (passport, driver’s license, or national ID). Provide proof of ownership of their app’s signing key (the private key used to sign APKs). List all current and all future application package names (com.example.myapp) they plan to use. Once registered and verified, apps from that developer can install normally. If a developer does not register or fails verification, their apps will be silently blocked by Google Play Protect on certified devices worldwide. This process turns what was once a simple “build and share APK” workflow into a permission-based system where Google acts as the gatekeeper for the entire Android ecosystem. 3. The “Adva

App Review rejected my iOS app under Guideline 2.1. The note said reviewers were unable to locate the App Tracking Transparency permission request when they tested the build. The prompt worked on my iPhone. Every single launch. It just didn't work on theirs. The cause turned out to be two properties of the ATT API that are easy to miss individually and genuinely nasty in combination: together they produce a bug that is invisible on a fast device and completely reproducible on a slow one. Your test device is fast. The reviewer's device is not necessarily. This post is the root cause, the fix I shipped, and the list of other things that silently suppress the prompt. The two facts that explain everything 1. iOS only presents the ATT prompt while your app is active Apple's documentation for requestTrackingAuthorization(completionHandler:) states, for iOS 15 and later: "Calls to the API only prompt when the application state is UIApplicationStateActive." That's UIApplication.State.active — not merely "in the foreground," and not "the code is running." During launch there is a window where your JS/UI is already executing but the app is still inactive : splash screen dismissal, the first render, a modal transition animating in or out. Call the API in that window and iOS declines to present. 2. When iOS declines to present, you don't get an error You get notDetermined back ( undetermined in expo-tracking-transparency ) — which is the exact same value you get when the user simply hasn't answered yet. There is no "I couldn't show it" signal. There is no thrown error. There is no presented: false flag. From the return value alone, "the user hasn't decided yet" and "iOS silently no-op'd your request" are indistinguishable. That's the trap. The API looks like it succeeded. The bug I shipped Reduced to its essentials: // Called during startup, while the splash screen was still going away. const { status } = await requestTrackingPermissionsAsync (); const granted = status === ' gr

"How much does it cost to put an app on the App Store" gets answered inconsistently online because most answers either only count Apple's fee, or only count hardware, or quietly assume you're renting expensive cloud infrastructure you don't actually need. Here's every cost, split into what's mandatory and what's a choice. Mandatory: Apple Developer Program — $99/year This is the one cost nobody can avoid. To submit any app to the App Store — free or paid, one app or fifty — you need an active Apple Developer Program membership, which is $99/year, billed annually, direct to Apple. There's no one-time version and no way around it. (There is a free-tier Apple ID for personal on-device testing without paying this, but it doesn't let you submit to TestFlight external testers or the App Store — for an actual public release, the $99/year membership is required.) Required, but where you have genuine choices: building and signing To submit a build, something has to run Xcode's command-line signing and archive tools — that part isn't optional. Where you have a choice is what runs it: Option Cost Recurring? Buy a Mac ~$799+ (Mac mini, entry price) No Rent a cloud Mac ~$20–100+/month Yes GitHub Actions, public repo $0 No GitHub Actions, private repo $0 up to a monthly allowance, then per-minute Only if you exceed the free allowance The short version on that last row: on a public repo, this line item can legitimately be $0, indefinitely. Optional or one-time: the things people assume cost more than they do App Store screenshots and marketing assets. You can generate these yourself for free — from the Simulator or a physical device — no paid tooling required. A physical iPhone for testing. Not strictly required to submit, but you'll want one to sanity-check the finished app before release. TestFlight itself. Free, included in the $99/year membership. App Store listing itself. Free — no fee to list an app beyond the membership. Adding it up For someone shipping a side project on a