> For the complete documentation index, see [llms.txt](https://docs.buildnatively.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildnatively.com/getting-started/other-platform-integrations/replit/integration.md). # Integration To ensure your Base44 app works smoothly once converted into a native mobile app, you’ll need to prepare your Base44 project in specific ways. These steps make sure navigation, login, payments, and notifications all work correctly inside iOS and Android apps. *** #### 1) Publish Your Base44 App with HTTPS * Your Base44 app must be live on a **secure HTTPS link**. * iOS and Android block **http\://** content for security reasons. * If any image, API, or script inside your Base44 app still uses `http://`, update it to `https://`. * Test by opening your app in Chrome or Safari → if you see a “Not Secure” warning, fix before moving forward. *** #### 2) Use a Single Primary Domain * Keep your app hosted on **one main domain** (for example, `app.example.com`). * Avoid sending users to different subdomains like `login.example.com` or `checkout.example.com`. * If certain flows must use a different domain (like Stripe or PayPal checkout), you’ll need to mark these links as **external** in BuildNatively. * Staying on one domain makes login, deep links, and navigation seamless. *** #### 3) Give Every Important Screen Its Own URL * Make sure all critical pages in your Base44 app can be reached via a **unique, stable URL**. * Examples: * `/login` → Login screen * `/signup` → Signup screen * `/profile` → Profile page * `/orders/123` → Order details * `/checkout` → Checkout page * Why this matters: * Push notifications can deeplink users directly to a page. * Social logins return users to the right screen after authentication. * Users can share or revisit pages reliably. *** #### 4) Avoid Popups for Critical Flows * Login, signup, onboarding, and checkout should not exist **only** as popups or modals. * Popups do not change the URL, which breaks: * Deep linking * Social login redirects * Push notification routing * Instead, design these flows as **dedicated full pages** in Base44. *** #### 5) Test Your App on Real Mobile Devices * Open your Base44 app in Safari (iPhone) and Chrome (Android). * Test every page and flow: * Do text and buttons fit the screen? * Are forms easy to complete without zooming? * Does scrolling feel smooth? * Do images and videos load quickly? * Fix any layout problems in Base44 before integrating with BuildNatively — the mobile app will display your web content exactly as it appears in a phone browser. *** #### 6) Plan for Login & Authentication * **Email/Password Login**: If it works in Safari/Chrome, it will also work inside your app. * **Google, Apple, or Facebook Login**: * These require **deep links** (Universal Links/App Links). * Make sure your Base44 login flow redirects users back to your app’s primary domain after login. * Later, enable **Social Auth + Deep Links** in BuildNatively to complete the setup. *** #### 7) Identify All External Links * Make a list of every link in your Base44 app that goes outside your domain. * Common examples: * Stripe or PayPal checkout * Calendly scheduling pages * YouTube or Vimeo video embeds * External Help Docs * In BuildNatively, configure these as **external links** so they open in Safari/Chrome instead of inside your app. * This prevents broken experiences or being “stuck” in the wrong view. *** #### 8) Prepare Checkout & Payments * If you’re using an external checkout provider (like Stripe), test your payment flow on a real mobile device. * If your checkout redirects to an external page, mark it as **external** in BuildNatively. * If you sell **digital goods or subscriptions** (courses, content, memberships), Apple and Google require you to use **In-App Purchases** instead of external payments. * If you sell **physical products or services**, Stripe/PayPal is fine. *** #### 9) Optimize Performance for Mobile * Compress large images (JPG/PNG) and videos before uploading. * Use lazy-loading where possible for heavy content. * Simplify your homepage design — the faster your app loads, the better the user experience. *** #### 10) Define Routes for Notifications & Deep Links * Push notifications and deep links depend on stable URLs. * Example flows: * A “New Message” notification should open `/messages/123`. * An “Order Shipped” notification should open `/orders/456`. * Make sure these routes exist in your Base44 project and open the correct content when tested in a browser. *** #### ✅ Summary of Integration Requirements Before wrapping your Base44 app with BuildNatively, confirm that: 1. Your Base44 app runs on **HTTPS** (no insecure content). 2. You’re using **one main domain** for internal navigation. 3. All key screens (login, signup, profile, checkout, orders) have **unique URLs**. 4. Login/signup/checkout are **full pages**, not only popups. 5. You’ve tested your app on real phones for **mobile readiness**. 6. Your login flow (especially with Google/Apple/Facebook) redirects back to your **primary domain**. 7. You have a list of **external links** (payments, scheduling, videos, docs) ready to configure. 8. Your checkout/payment flow works correctly and follows **App Store rules**. 9. Large media is optimized for **fast mobile performance**. 10. All notification and deep link routes exist as **real pages with URLs**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buildnatively.com/getting-started/other-platform-integrations/replit/integration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.