Store Guidelines

Understanding app store policies is crucial when using WebF’s over-the-air update capabilities. This guide explains how WebF complies with both Apple App Store and Google Play Store guidelines.

iOS App Store Review

WebF apps comply with Apple’s App Store guidelines for interpreted code. According to the Apple Developer Program License Agreement (Section 3.3.1b), interpreted code may be downloaded to an application as long as it:

(a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store,

(b) does not create a store or storefront for other code or applications, and

(c) does not bypass signing, sandbox, or other security features of the OS.

How WebF Complies

WebF is fully compliant with these requirements:

HTML/CSS: Parsed by WebF’s built-in interpreter
JavaScript: Executed using QuickJS as the interpreter
No bypassing: All code runs within the iOS sandbox without bypassing security features
Standard practice: Over-the-air updates via WebF follow the same industry-standard practice as other code push solutions

Best Practices for Compliance

✅ Allowed:

UI updates and styling changes
Bug fixes and performance improvements
Content updates (text, images, layouts)
Feature enhancements that align with your app’s original purpose
A/B testing variations
Localization and internationalization updates
Analytics and tracking improvements

❌ Not Allowed:

Fundamentally changing the app’s purpose after submission
Creating an app store or marketplace for other applications
Loading executable code that bypasses iOS security
Adding major features inconsistent with your app’s advertised purpose
Changing app category or target audience without review
Implementing functionality that requires new permissions without review

Key Principle

So long as your application is not engaging in deceptive behavior via updates (e.g., changing the purpose of the app via update), updating via WebF is standard industry practice and compliant with App Store guidelines.

Examples: Compliant vs Non-Compliant

✅ Compliant Updates

Example 1: E-commerce App

Initial submission: Shopping app for clothing
OTA updates: New product layouts, checkout flow improvements, seasonal themes
Why compliant: Enhances the shopping experience without changing the app’s purpose

Example 2: News App

Initial submission: News reader with article feeds
OTA updates: New article layouts, reading mode, social sharing improvements
Why compliant: Improves the news reading experience within the original scope

Example 3: Restaurant App

Initial submission: Restaurant menu and ordering
OTA updates: Menu updates, UI refinements, new payment options
Why compliant: Enhances restaurant services as originally intended

❌ Non-Compliant Updates

Example 1: Category Change

Initial submission: Educational flashcard app
OTA update: Becomes a social media platform
Why non-compliant: Fundamentally changes the app’s purpose and category

Example 2: App Store Creation

Initial submission: Game launcher
OTA update: Becomes a marketplace to download other games
Why non-compliant: Creates a store for other applications (violation of 3.3.1b)

Example 3: Deceptive Behavior

Initial submission: Simple calculator app
OTA update: Adds cryptocurrency trading features
Why non-compliant: Adds major functionality inconsistent with original purpose

Review Process Considerations

When submitting your WebF app for review:

Be transparent: Clearly describe your app’s features and mention that content may be updated
Document functionality: Ensure your App Store description accurately reflects all features
Test thoroughly: Submit a fully functional version, not a shell that loads everything remotely
Show value: Demonstrate the app’s core functionality during review
Stay consistent: Keep your updates aligned with your original app submission

Official Resources

Google Play Store

Google Play Store has two key restrictions relating to update tools and dynamic code:

Policy 1: Update Mechanisms and Interpreters

According to Google Play’s update policy :

An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play’s update mechanism. Likewise, an app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).

Apps or third-party code, like SDKs, with interpreted languages (JavaScript, Python, Lua, etc.) loaded at run time (for example, not packaged with the app) must not allow potential violations of Google Play policies.

How WebF Complies

WebF is fully compliant because it uses interpreters:

HTML/CSS: Parsed by WebF’s built-in interpreter
JavaScript: Executed using QuickJS interpreter (not compiled native code)
No executable code: WebF does not download .dex, .jar, or .so files
Interpreter exception: Falls under the explicit exception for “code that runs in a virtual machine or an interpreter”

This is the same compliance mechanism used by other standard tools like web browsers, React Native’s Metro bundler, and other code push solutions.

Policy 2: No Deceptive Behavior

According to Google Play’s deceptive behavior policy :

Changes to the app must not be deceptive (e.g., changing the purpose of the app via update).

Best Practices

Please be clear with your users about what you are providing with your application and do not violate their expectations with significant behavioral changes through the use of WebF.

✅ Allowed:

Remote content updates that enhance the user experience
Bug fixes and UI improvements via web updates
Content and layout changes
Feature improvements aligned with the app’s purpose
Updates that users would reasonably expect based on your app’s description

❌ Not Allowed:

Fundamentally changing app behavior without review
Changing the purpose of the app via update (deceptive behavior)
Implementing malicious or harmful functionality
Violating user privacy expectations
Adding functionality that contradicts your app’s description

Key Differences from iOS

Google Play is generally more permissive than Apple’s App Store regarding remote updates:

More flexibility: Google allows broader interpretation of “core functionality”
Explicit interpreter exception: Clear policy allowing interpreted code updates
Less strict review: Updates are typically not scrutinized as heavily
Faster iteration: OTA updates can include more substantial changes
Still has limits: Must not violate security, privacy, or deceptive behavior policies

Official Resources

Platform Comparison

Aspect	iOS App Store	Google Play Store
Policy strictness	Strict interpretation	More flexible
Update scope	Must align with original purpose	Broader interpretation of purpose
Review process	Manual review required	Automated + spot checks
Update speed	Consider review time	Faster deployment
Risk level	Higher rejection risk if misused	Lower but still present

Common Questions

Can I use WebF for production apps?

Yes. WebF is designed for production use and many apps successfully use it while remaining compliant with app store policies.

How much can I change via OTA updates?

Guideline: You can update anything that enhances or refines your app’s original functionality, but avoid fundamental changes to purpose or adding unrelated features.

Do I need to mention WebF in my app submission?

Not specifically. You should describe your app’s features accurately, but you don’t need to detail the technical implementation (WebF, Flutter, etc.).

What if my app gets rejected?

If rejected for policy violations:

Review the rejection reason carefully
Adjust your OTA update strategy if needed
Ensure updates align with your app’s original submission
Provide clarification to the review team if there’s a misunderstanding
Consider making significant changes through app updates rather than OTA

Can I use WebF for gaming apps?

Yes, but be mindful:

Game content and levels can be updated
Core game mechanics should be present in the original submission
Don’t download entirely new games via OTA
Multiplayer features and events are typically fine to update

What about apps with user-generated content?

Allowed, as long as:

The ability to display user content was in the original submission
You have appropriate content moderation
The app’s purpose includes user-generated content
You follow platform guidelines for user safety

Best Practices Summary

Do’s ✅

Be transparent about your app’s functionality
Document features in your app store listing
Test before submitting to ensure compliance
Update responsibly within your app’s scope
Monitor feedback from users and reviewers
Keep records of what was in original submission vs OTA updates
Review guidelines regularly as policies evolve

Don’ts ❌

Don’t change your app’s fundamental purpose
Don’t create app stores or marketplaces
Don’t bypass platform security features
Don’t mislead users about functionality
Don’t add unrelated features via OTA
Don’t ignore rejection feedback
Don’t test compliance in production

Getting Help

If you’re unsure whether your OTA update strategy complies with app store policies:

Consult Apple/Google documentation first
Join WebF Discord to discuss with the community
Review similar apps in your category
Contact app store review teams for clarification if needed
Consider legal consultation for high-stakes applications

Updates to This Guide

App store policies evolve over time. Check back regularly for updates, and always refer to the official Apple and Google documentation for the most current policies.

Last updated: Based on policies as of 2025.

Next Steps

Deployment Guide - Learn how to deploy your WebF app
Advanced Topics - Optimize your app’s performance
Getting Started - Begin integrating WebF into Flutter