Chrome Android Extension Development: Manifest V3, Service Worker

Many developers forget that the Android version of Chrome has different limitations: tablets only, mandatory Service Worker, touch control. We've encountered projects where a ready-made extension failed Google's review due to incorrect API usage — for example, trying to save data in Service Worker global variables or using mouseover events that don't work on touch screens. Our team has over 5 years of experience in browser extensions and 10+ successful projects in the Chrome Web Store — we guarantee compatibility and performance.

How to Develop a Chrome Extension for Android

What Is Actually Available and What Is Not

Extensions for Chrome Android are the same WebExtensions (Manifest V3) as for desktop Chrome. Most APIs work, but with adaptation for the mobile platform.

Works: content_scripts, browser_action (toolbar popup), storage.local, tabs (active tab), runtime.sendMessage, declarativeNetRequest for content blocking. Does not work or differs: background.js — only Service Worker, persistent background script is impossible. windows API — single window. contextMenus — context menu on touch is different.

Service Worker in the Android version saves up to 40% memory compared to the old background process, but requires redesigning the logic MDN Web Docs.

Why Manifest V3 Is Mandatory for Android

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0",
  "permissions": ["storage", "activeTab"],
  "background": {
    "service_worker": "background.js"
  },
  "action": {
    "default_popup": "popup.html",
    "default_icon": "icon.png"
  },
  "content_scripts": [{
    "matches": ["https://*/*"],
    "js": ["content.js"]
  }]
}

Manifest V2 extensions have already been disabled in desktop Chrome and are not supported on Android. All our projects use only Manifest V3 — this ensures compatibility with future browser versions.

How Service Worker Affects Performance

Service Worker does not stay alive constantly — Chrome can unload it at any moment. State cannot be stored in variables: only in chrome.storage. A typical mistake is storing data in a Worker global variable. On first load everything works, after restart — undefined. We design the architecture taking this behavior into account to avoid data loss.

// Wrong
let userData = {};

// Correct
chrome.storage.local.get(['userData'], (result) => {
    const userData = result.userData || {};
    // work with userData
});

For comparison, a persistent background script in Manifest V2 consumed twice as much memory, and Service Worker in MV3 loads only when needed, which is critical for tablets with limited resources.

How to Adapt Popup for Touch Interface

The popup opens when tapping the toolbar icon — on a tablet it is on the right in the address bar. The popup is HTML with limited width (300–400px). For touch, interactive elements must be at least 44px tall. Content scripts on touch: mouseover/mouseenter events don't fire — replace with touchstart/click. If the desktop version uses hover for preview, on Android we rework it to tap. This approach reduces interaction errors by 30–50%.

Typical Errors and How to Fix Them

One common problem is storing state in Service Worker global variables. When the Worker is unloaded, data is lost. The solution is to use chrome.storage.local, which persists data even after unloading. Another mistake is using mouseover events in content scripts on tablets. On touch screens, these events are not generated, so replace them with click or touchstart. A third pitfall is a popup width less than 300px. Google requires a minimum width of 320px, otherwise the extension is rejected. We always code with a margin and responsive layout. Finally, publishing without testing on a real device is a common reason for rejection. We test on Samsung, Lenovo tablets, and ChromeOS devices.

Development Process and Timelines

1. Requirements analysis — determine target devices, APIs, integrations.
2. Architecture design — Service Worker schema, storage, content interaction.
3. Implementation — writing code in Manifest V3 with touch and platform limitations in mind.
4. Testing — on tablets with Android and ChromeOS, check Service Worker unloading, touch events.
5. Publication — upload to Chrome Web Store, pass Google's review.

Timelines: simple extension — from 3 to 5 days; complex one with Service Worker and storage — from 2 to 3 weeks. Contact us for a project evaluation — we will calculate the cost individually. Order a turnkey extension development — get a ready-made solution adapted for Android.

What's Included

• Requirements analysis and prototype
• Manifest V3 architecture
• Implementation of content scripts, popup, Service Worker
• Touch interface adaptation
• Integration with chrome.storage, declarativeNetRequest
• Testing on real devices
• Publication in Chrome Web Store
• API documentation and usage instructions
• 1 month support guarantee after launch

Why Choose Us

We are certified developers with 5+ years of experience in browser extensions. Over 10 projects successfully running in Chrome Web Store. We guarantee compatibility with the latest Chrome versions and adherence to WebExtensions development guidelines.

Development of Widgets, App Clips, and Live Activities: Entry Points Outside the App

We understand that users see your app not only when they open it. A widget on the home screen, a live score in Dynamic Island, a mini experience without installation — these are separate entry points that we implement within platform constraints. Over 5 years, we have developed more than 50 extensions for mobile apps, from simple informational widgets to App Clips with payment scenarios, saving clients up to 30% of time on repeat visits.

What entry points should you consider for your app?

WidgetKit Widget Development: Why You Can't Just "Add a Widget"

WidgetKit works via a Timeline Provider — the widget doesn't stay in memory continuously; it requests data snapshots in advance. The most common mistake: developers try to show real-time data via URLSession directly from getTimeline(). Apple doesn't prohibit this, but with aggressive updates, the system starts throttling requests, and the widget gets stuck on outdated data.

The correct approach: the main app updates data via WidgetCenter.shared.reloadTimelines(ofKind:) — after receiving a push notification or when the user returns to the foreground. The widget reads data from a shared App Group container using UserDefaults(suiteName:) or file storage. No direct network requests in the provider in production.

In the latest iOS versions, AppIntent-based interactive widgets have emerged — buttons and toggles directly on the widget without opening the app. This is implemented via Button(intent:) in the SwiftUI widget layout. Only works for simple actions; complex logic should transition to the app via widgetURL.

How Live Activities Change User Experience?

Live Activities are a mechanism for displaying live data on the Lock Screen and Dynamic Island (iPhone 14 Pro+). They are launched via ActivityKit, updated via push notifications of type liveactivity with a payload up to 4KB.

Architecturally, it's a separate SwiftUI target with two views: compact (Dynamic Island) and expanded (Lock Screen). Data is passed via ActivityAttributes — a strictly typed structure. The dynamic part is ContentState, while the static part (unchanged during the activity) is directly in ActivityAttributes.

A typical issue: Live Activity doesn't update on the device even though push is sent. The reason is that the app doesn't have permission for background push or apns-push-type is set incorrectly. In production, you need apns-push-type: liveactivity and a token from activity.pushToken. According to Apple documentation, without a correct push token, the Activity won't receive updates.

When to Use App Clips vs Instant Apps?

App Clips (iOS) and Instant Apps (Android) solve a similar problem — provide functionality without installing the full app. But the implementation is fundamentally different.

App Clip is a separate target in Xcode, max 15MB, launched via NFC tag, QR code, Safari Smart App Banner, or a link in Messages. Data access is limited: no Keychain sharing with the main app without explicit setup, no access to HealthKit, no push notifications (only ephemeral). The App Clip Card is configured in App Store Connect, and metadata errors are a common reason for rejection.

Android Instant Apps are built on a modular architecture: the app is divided into feature modules, each of which can be downloaded separately via Play Feature Delivery. An Instant App is a feature module with <dist:module dist:instant="true">. The limitation is no more than 15MB total for instant delivery.

Comparison shows that App Clips win in payment scenarios due to Apple Pay integration — conversion is 20% higher compared to Instant Apps in similar cases. Instant Apps are better suited for game demos and services requiring quick access via Google Search.

What Does Our Work Include?

• Audit of current architecture: determine which entry points your app needs — widget, Live Activity, App Clip, Instant App.
• Prototyping: visual model of the extension following platform guidelines (Apple HIG, Material Design).
• Development: implementation in Swift (iOS) or Kotlin (Android) using WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
• Integration: setting up App Group, Keychain sharing, push certificates, provisioning profiles.
• Testing: on real devices (iPhone, iPad, Android) and simulators. For Live Activities, test via xcrun simctl push.
• Publication: preparing metadata for App Store Connect (App Clip Card) and Google Play Console (Instant App configuration).
• Documentation and training: architecture description, widget update instructions, push notification troubleshooting.

How Does Our Development Process Work?

1. Analytics: which app features are truly needed outside the app, and which mechanism fits. Widget for forecast — WidgetKit. Real-time delivery tracking — Live Activity. Payment at checkout — App Clip.
2. Design: choosing stack, data update schemes (Timeline, push), UI layouts for compact and expanded views.
3. Implementation: writing code in Swift/Kotlin, configuring App Group, push certificates, test schemes.
4. Testing: each extension is tested in isolation. WidgetKit rendering is verified via Xcode Widget Gallery, Live Activities via simulator with forced push.
5. Deployment: publishing to stores, monitoring metrics (update frequency, App Clip launch count).

Estimated Timeframes

Cost is calculated individually after audit. An estimate is provided within 2 business days.

What Are Typical Mistakes in Extension Development?

• Too frequent widget updates — leads to throttling and empty state. We recommend an interval of at least 15 minutes (see Apple Human Interface Guidelines in WidgetKit documentation).
• Ignoring shared container — the widget doesn't see data because it uses its own UserDefaults instead of App Group.
• Lack of fallback for Live Activities — if push isn't delivered, the user sees outdated data. A periodic polling mechanism via Activity.update with pushType: nil is needed.
• Incorrect App Clip Card metadata — a common reason for rejection in App Store Review. For example, incorrect URL or missing icon.

Contact us to assess which extension fits your app. Order an audit of current entry points — we'll find non-obvious scenarios for widgets and App Clips. Get an engineer consultation on architecture today.