English

Mobile Readiness Scan

Run condoo.Vibe's Mobile Readiness Scan to find mobile issues in your project, fix them, and prepare for Android or iOS export.

Before exporting your condoo.Vibe application for Android or iOS, you should make sure the project is ready for a mobile environment.

condoo.Vibe's Mobile Readiness Scan analyzes your application and helps identify issues that could affect the mobile experience.

Instead of discovering these problems after creating your mobile build, you can find and resolve them first.

Scan first. Fix what matters. Export when your application is ready.

What Is the Mobile Readiness Scan?

A web application and a mobile application don't always behave in exactly the same way.

Your project might work perfectly in a desktop browser while still containing elements that need attention before mobile export.

The Mobile Readiness Scan helps identify those issues.

The workflow is:

condoo.Vibe PROJECT
     ↓
MOBILE READINESS SCAN
     ↓
ANALYZE APPLICATION
     ↓
READINESS RESULTS
     ↓
FIX ISSUES
     ↓
SCAN AGAIN
     ↓
EXPORT

Think of it as a pre-flight check before generating your mobile application.

When Should You Run a Scan?

Run the Mobile Readiness Scan after the main application is working and you're preparing to move toward Android or iOS.

Ideally:

BUILD
  ↓
TEST
  ↓
MOBILE OPTIMIZE
  ↓
READINESS SCAN
  ↓
FIX
  ↓
EXPORT

Don't wait until you've already submitted your application to an app store to discover basic mobile issues.

Run Your First Scan

Open the project you want to prepare for mobile.

Navigate to the Mobile Export area and start the Mobile Readiness Scan.

condoo.Vibe Mobile Scan

condoo.Vibe will analyze the project and determine whether there are areas that should be addressed before export.

Once the analysis completes, review the results.

Understanding Your Scan Results

The readiness results help you understand the state of your application before creating a mobile build.

condoo.Vibe Mobile Scan Results

Depending on your project, condoo.Vibe may identify items that require attention or improvements before export.

Don't think of a readiness issue as:

My application is broken.

Instead, think of it as:

There's something I should address before packaging this application for mobile.

What condoo.Vibe Is Looking For

Mobile readiness involves more than visual responsiveness.

condoo.Vibe needs to consider whether important parts of your application can provide a usable experience in a mobile environment.

Depending on your application, areas worth reviewing include:

Not every project will have the same issues.

A simple business website and a complex CRM have very different mobile requirements.

Responsive Layouts

One of the first things to check is whether the interface adapts properly to smaller screens.

For example, a desktop layout might be:

┌───────────────────────────────────────┐
│ Sidebar │ Dashboard                   │
│         │                             │
│         │ Card │ Card │ Card │ Card   │
│         │                             │
│         │ Large Data Table            │
└───────────────────────────────────────┘

That shouldn't simply be squeezed into a phone-sized screen.

A mobile layout might become:

┌─────────────────────┐
│ ☰  Dashboard        │
├─────────────────────┤
│ Revenue             │
├─────────────────────┤
│ Customers           │
├─────────────────────┤
│ MRR                 │
├─────────────────────┤
│ Activity            │
└─────────────────────┘

The information remains available, but the presentation adapts.

Desktop navigation patterns don't always translate well to mobile.

For example, a permanent sidebar may need to become:

Test whether users can easily move between the application's most important areas.

Ask yourself:

Could someone comfortably use this application with one hand on a phone?

Touch Targets

Buttons and controls need to be easy to tap.

A tiny icon that works perfectly with a mouse may be frustrating on a touchscreen.

Review:

Avoid placing several tiny interactive elements too close together.

Forms

Forms are one of the most important areas to test.

Suppose your desktop form looks like:

First Name       Last Name

Email            Phone

Company          Website

Address          City

On mobile, stacking the fields may provide a better experience:

First Name

Last Name

Email

Phone

Company

Website

Address

City

Also check:

Tables

Tables are common in SaaS applications, CRMs, admin dashboards, and internal tools.

They're also one of the easiest desktop patterns to get wrong on mobile.

Imagine:

Name | Email | Company | Plan | Status | Created | Actions

Trying to display every column on a narrow phone screen may create horizontal scrolling or unreadable content.

Instead, consider displaying the most important information first.

For example:

Sarah Chen
Acme Ltd.
Agency

Active

[View]

Then show the remaining information on the detail screen.

Modals and Dialogs

Check whether dialogs fit inside smaller screens.

A modal designed for desktop can sometimes:

For mobile, dialogs should remain accessible and usable throughout the interaction.

Authentication

Test the complete authentication experience on mobile.

This includes:

Sign Up
   ↓
Verify / Authenticate
   ↓
Sign In
   ↓
Protected Application
   ↓
Sign Out

If you're using Google authentication or another external authentication flow, test that as well.

Authentication is too important to assume it will behave correctly simply because it works on desktop.

Images and Media

Large images can affect the mobile experience.

Check:

An image that looks impressive across a desktop screen may dominate too much of the interface on mobile.

Your application may open:

Test what happens when these links are opened from the mobile experience.

Make sure users can complete the workflow and return to the application where appropriate.

Integrations

If your application depends on connectors, include them in your mobile testing.

For example:

Mobile App
    ↓
Booking
    ↓
Google Calendar
    ↓
Resend
    ↓
Confirmation

Don't only check whether the booking button works.

Test the complete workflow.

Fixing Readiness Issues

If the scan identifies something that needs attention, work through the issues before exporting.

For example, you might tell condoo.Vibe:

Optimize the customer dashboard for mobile based on the readiness issues identified. Preserve the current desktop experience and functionality.

Or:

Fix the mobile navigation and table issues identified by the readiness scan without changing the existing desktop layout.

condoo.Vibe can then work on the specific areas that need improvement.

Don't Fix Everything by Redesigning Everything

A readiness issue doesn't necessarily require a complete redesign.

For example, if the problem is:

Customer table doesn't fit on mobile.

Don't immediately ask:

Completely redesign my entire CRM.

Instead:

Make the customer table usable on mobile while preserving the existing desktop table and functionality.

Smaller, targeted changes reduce the risk of breaking working parts of your application.

Preserve the Desktop Experience

Mobile optimization shouldn't unnecessarily damage the desktop version.

Tell condoo.Vibe when both experiences matter.

For example:

Optimize this dashboard for mobile screens while preserving the current desktop layout for larger screens.

Conceptually:

               APPLICATION
                   ↓
          RESPONSIVE EXPERIENCE
             ↙           ↘
         DESKTOP         MOBILE

The same application can adapt to the device being used.

Re-Run the Scan

After addressing the identified issues, run the Mobile Readiness Scan again.

condoo.Vibe Improved Scan Results

The process is intentionally iterative:

SCAN
 ↓
ISSUES
 ↓
FIX
 ↓
SCAN AGAIN
 ↓
MORE ISSUES?
 ↙       ↘
YES       NO
 ↓         ↓
FIX      EXPORT

Don't assume that making one change means the entire application is ready.

Test Manually Too

The Mobile Readiness Scan is a useful tool, but it shouldn't replace actually using your application.

Open the mobile preview and walk through the important customer journeys.

For example, for an e-commerce application:

Open App
   ↓
Browse Products
   ↓
View Product
   ↓
Add to Cart
   ↓
Checkout
   ↓
Confirmation

For a CRM:

Login
 ↓
View Leads
 ↓
Open Lead
 ↓
Update Status
 ↓
Add Note
 ↓
Create Follow-Up

The goal is to determine whether the product feels usable, not merely whether the interface technically fits.

Test Different Screen Sizes

Mobile devices aren't all the same size.

An application that looks good on a large phone may have problems on a smaller one.

Pay particular attention to:

Avoid designing for only one specific phone.

Portrait Orientation

Most users will interact with your application in portrait orientation.

Make sure the primary workflows work comfortably in that layout.

For example:

┌───────────────────┐
│                   │
│      YOUR APP     │
│                   │
│                   │
│                   │
│                   │
└───────────────────┘

Don't depend on users rotating their phone just to complete ordinary tasks.

Check for Horizontal Scrolling

Unexpected horizontal scrolling is often a sign that something doesn't fit properly.

Common causes include:

If the whole application moves sideways while users scroll, investigate which component is causing the overflow.

Check Fixed Elements

Applications sometimes use fixed:

Make sure these don't cover important content on smaller screens.

For example:

┌─────────────────────┐
│ Content             │
│                     │
│                     │
│                     │
│ [Important Button]  │
├─────────────────────┤
│ Fixed Navigation    │
└─────────────────────┘

The navigation shouldn't hide the button above it.

Test Empty States

Don't only test screens full of sample data.

Test what a new user sees.

For example:

Projects

You haven't created a project yet.

[Create Your First Project]

A mobile user should understand what to do next even when the screen contains no data.

Test Error States

Also test what happens when something goes wrong.

For example:

Payment failed

We couldn't complete your payment.

[Try Again]

or:

Unable to load projects.

[Retry]

Errors shouldn't create unusable screens or trap the user.

Mobile Performance

Mobile users may have slower connections and less powerful devices than desktop users.

Avoid unnecessarily heavy experiences where possible.

Be mindful of:

A beautiful application that feels slow can still provide a poor mobile experience.

Payments Require Special Attention

If your application involves payments, don't treat mobile readiness as only a layout problem.

Applications distributed through Google Play or Apple's App Store may be subject to store-specific payment requirements depending on what you're selling.

Before submission, make sure the payment model complies with the requirements of the store you're targeting.

We'll discuss store submission separately.

A Good Mobile Optimization Prompt

A strong prompt could look like:

Review the application for mobile readiness. Preserve the current desktop experience. Optimize the navigation, dashboard cards, customer tables, forms, dialogs, and primary workflows for smaller touch screens. Avoid unnecessary horizontal scrolling and ensure important actions remain easy to access. Don't remove any existing functionality.

That's much stronger than:

Make it mobile friendly.

Use Plan Mode for Complex Applications

For a large application, consider planning the mobile adaptation before changing anything.

For example:

Analyze this application for mobile use. Identify which layouts, navigation patterns, tables, forms, dialogs, and workflows need to change for a good mobile experience. Create a plan only. Don't modify the application yet.

Review the plan.

Then implement the changes.

EXPLORE
   ↓
PLAN
   ↓
REVIEW
   ↓
BUILD
   ↓
SCAN

When Is Your Application Ready?

Mobile readiness doesn't mean:

Every screen looks exactly like the desktop version.

It means the important application experiences work effectively on mobile.

Before export, you should be confident that users can:

without fighting the interface.

Mobile Readiness Checklist

Before moving to export, check:

Then you're ready for the next stage.

From Scan to Export

The process should look like:

WORKING WEB APP
       ↓
MOBILE READINESS SCAN
       ↓
REVIEW RESULTS
       ↓
FIX ISSUES
       ↓
TEST
       ↓
SCAN AGAIN
       ↓
READY
       ↓
MOBILE EXPORT

The scan isn't an obstacle between you and your mobile app.

It's there to help make sure what you export is actually ready to be used.

Next: Export for Android (APK)

Your application is mobile-ready.

Next, we'll take it to Android.

We'll cover: