{"id":146,"date":"2026-07-27T08:35:03","date_gmt":"2026-07-27T08:35:03","guid":{"rendered":"https:\/\/mobilions.com\/blog\/?p=146"},"modified":"2026-07-27T08:36:24","modified_gmt":"2026-07-27T08:36:24","slug":"custom-android-app-development","status":"publish","type":"post","link":"https:\/\/mobilions.com\/blog\/custom-android-app-development\/","title":{"rendered":"Custom Android App Development: A Complete 2026 Guide"},"content":{"rendered":"\n

Most guides on custom android app development<\/strong> treat the word \u201ccustom\u201d as filler and jump straight to a cost table. It is not filler. Custom means the app is built from scratch for your specific business, on a real engineering stack, instead of assembled from a template or a no-code builder that you will outgrow in a year. Having shipped Android apps for years, I can tell you that distinction is the whole decision, because it changes what you can build, what it costs, and whether the app survives contact with the real Android world, which is far messier than the iOS one.<\/p>\n\n\n\n

Here is the honest version up front. Android reaches more people than any other mobile platform, roughly 70 percent of the world\u2019s phones run it, so the opportunity is enormous. But that reach comes from more than a thousand device makers and a wide spread of operating-system versions, and that diversity, called fragmentation, is the single thing that makes Android engineering genuinely hard.<\/p>\n\n\n\n

A custom app built on the modern Android stack, Kotlin and Jetpack Compose, with fragmentation handled deliberately, is a very different product from a cheap template that looks fine on the developer\u2019s own phone and breaks on half the devices in the field. This guide covers what custom really means, the modern stack, the fragmentation problem, the Android-specific constraints, cost, and the mistakes that quietly sink these builds.<\/p>\n\n\n\n

Key takeaways<\/strong><\/h2>\n\n\n\n

If you only have a minute, these are the points that matter most about custom android app development.<\/p>\n\n\n\n

Custom means built for your business on a real stack, not assembled from a template. It costs more up front and is worth it when you need control, scale, or integrations a builder cannot give you.<\/p>\n\n\n\n

Android\u2019s reach is unmatched but so is its fragmentation. About 70 percent of phones run Android, spread across more than a thousand manufacturers and many OS versions, and handling that spread is the real engineering work.<\/p>\n\n\n\n

The modern stack is Kotlin and Jetpack Compose. Google recommends Compose for new apps, and it is what serious teams build on in 2026, not the older XML View system.<\/p>\n\n\n\n

Cost scales with complexity, not screens. A simple custom app runs about $15,000 to $40,000, and a complex one with real integrations runs $100,000 to $250,000 or more, with the difference driven by backend, integrations, and device coverage.<\/p>\n\n\n\n

What does \u201ccustom\u201d Android app development actually mean?<\/strong><\/h2>\n\n\n\n

The useful way to think about it is a spectrum of control. At one end are no-code builders and templates, which are fast and cheap and fine for a simple, standard app, but you are limited to what the builder supports and you do not own the underlying code in any meaningful way. At the other end is custom development, where engineers build the app from the ground up in real code, which means you can build exactly what your business needs, integrate with any system, own the codebase, and scale without hitting a wall.<\/p>\n\n\n\n

Custom is the right call when your app is core to the business rather than a marketing afterthought, when it needs to integrate with your existing systems, when it handles real data or real scale, or when the experience itself is a competitive advantage. It is the wrong call, honestly, for a simple brochure app that a template would handle for a fraction of the cost. Part of doing this well is being clear-eyed about which one you actually need, because paying for custom when a template would do is as much a mistake as the reverse. When we scope mobile app development<\/a> with clients, that honest sort is the first conversation.<\/p>\n\n\n\n

Why build for Android?<\/strong><\/h2>\n\n\n\n

The case for Android is reach. Around 70 percent of the world\u2019s mobile devices run Android according to Statcounter\u2019s global data<\/a>, and in many of the fastest-growing markets that figure is far higher. If your users are global, or outside the wealthiest markets, or simply broad, Android is not the secondary platform, it is the primary one. Android also gives developers more freedom than iOS: deeper access to the system, more flexible distribution including outside the Play Store, and fewer constraints on what an app can do in the background, though those freedoms come with the responsibility to handle them well.<\/p>\n\n\n\n

The flip side of that reach is the thing the next sections are really about. Serving 70 percent of the world\u2019s phones means serving an enormous range of devices, and that is where custom android app development stops being a UI exercise and becomes real engineering.<\/p>\n\n\n\n

What is the modern Android stack in 2026?<\/strong><\/h2>\n\n\n\n

If a vendor proposes to build your custom Android app on the old Java and XML View system, that is a signal to look elsewhere, because the platform has moved on. The modern stack is Kotlin as the language and Jetpack Compose as the UI toolkit.<\/p>\n\n\n\n

\"Modern<\/figure>\n\n\n\n

Kotlin<\/a> is Google\u2019s preferred language for Android, and it is more concise and safer than Java, particularly around the null-pointer errors that caused a huge share of old Android crashes. Jetpack Compose<\/a> is Google\u2019s modern, declarative UI toolkit, and Google now recommends it for new apps. Instead of describing screens in XML and wiring them up with boilerplate, you build the UI in Kotlin as functions that react to state, which means less code, live previews, and far simpler state management. It is not a toy or an early bet, either. Airbnb, Disney+, Spotify, Meta\u2019s Threads, and Google Play itself are built with Compose.<\/p>\n\n\n\n

Around those two sits the rest of a real architecture, and the specific names matter less than the fact that they exist and are used deliberately.<\/p>\n\n\n\n

Layer<\/th>Modern choice<\/th>What it does<\/th><\/tr><\/thead>
Language<\/td>Kotlin<\/td>Concise, null-safe, Google\u2019s preferred Android language<\/td><\/tr>
UI<\/td>Jetpack Compose<\/td>Declarative UI in Kotlin, Google-recommended for new apps<\/td><\/tr>
Architecture<\/td>MVVM or Clean, with a clear separation of concerns<\/td>Keeps the app testable and maintainable as it grows<\/td><\/tr>
Async<\/td>Kotlin Coroutines and Flow<\/td>Handles background work and data streams cleanly<\/td><\/tr>
Local data<\/td>Room<\/td>A reliable local database layer<\/td><\/tr>
Dependency injection<\/td>Hilt<\/td>Wires the app together without brittle manual plumbing<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

<\/p>\n\n\n\n

You do not need to memorize this list. You need to make sure whoever builds your app is using something like it rather than a decade-old approach, because the stack is what determines whether the app is maintainable two years from now.<\/p>\n\n\n\n

The hard part: Android fragmentation<\/strong><\/h2>\n\n\n\n

This is the section the cost guides skip, and it is the one that actually separates a custom Android app that works from one that does not. Android runs on devices from more than a thousand manufacturers, across thousands of distinct models, with wildly different screen sizes, chipsets, memory, sensors, and manufacturer skins layered on top of the base system.<\/p>\n\n\n\n

On top of the hardware spread there is version spread. Per Statcounter\u2019s Android version data<\/a>, as of mid-2025 Android 14 held the largest share while Android 15 was rolling out and the newest Android 16 was climbing fast, all while older versions from Android 10 through 13 still held meaningful share, and that mix shifts by country. For contrast, on iOS the vast majority of active iPhones run one of the last couple of releases. Android is simply a far wider target.<\/p>\n\n\n\n

\"Android<\/figure>\n\n\n\n

Fragmentation is not an abstract worry. It shows up as a bug that only appears on one manufacturer\u2019s skin, a layout that breaks on a foldable or a tablet, a feature that works on Android 15 but crashes on Android 11, or a performance problem that only surfaces on budget chipsets. <\/p>\n\n\n\n

The teams that handle it well do a few specific things: they use real user data to decide which devices and OS versions actually matter for their audience rather than trying to support everything equally, they test on a blend of emulators for speed and real devices for the hardware-specific issues, they gate risky features behind flags and roll them out progressively, and they monitor crashes and performance broken down by device model and OS version so a device-specific problem is visible instead of hidden in an average. Fragmentation is manageable, but only if it is treated as a first-class design constraint from the start, not discovered in the support queue after launch.<\/p>\n\n\n\n

What Android-specific constraints should you design around?<\/strong><\/h2>\n\n\n\n

Beyond fragmentation, a few Android realities shape a custom build and are worth knowing before you scope one.<\/p>\n\n\n\n

Background execution is restricted and has gotten stricter with each release. Modern Android limits what an app can do when it is not in the foreground to protect battery, so anything that needs to run in the background, location tracking, syncing, long uploads, has to use the right system mechanism rather than assuming it can just keep running. Getting this wrong is a top cause of features that work in testing and fail on real phones.<\/p>\n\n\n\n

Permissions are increasingly granular and user-controlled, so an app has to request access at the right moment and behave gracefully when a user says no. Google Play policies are strict and actively enforced, covering data handling, permissions, target-API requirements, and more, and an app that ignores them can be rejected or pulled, so compliance is a design input, not a launch-day checklist. <\/p>\n\n\n\n

<\/p>\n\n\n\n

Play submission itself is a real step to plan for rather than a formality: Google reviews new apps and updates, a rejection can cost days, and every year Google raises the minimum target API level that apps must meet to stay updatable, so an app that is not maintained slowly ages out of the store. None of this is a reason to avoid Android, but all of it is a reason to build with the store\u2019s rules in mind from day one, the same way our mobile app development<\/a> team treats compliance as part of the architecture rather than a final gate. <\/p>\n\n\n\n

And security matters more on Android precisely because the ecosystem is open, which means encrypting data at rest, using the platform\u2019s secure storage, and not trusting the device are baseline, not extras. This is also where a custom Android build often needs to be scoped together with the custom software<\/a> and backend it talks to, rather than as an isolated mobile project.<\/p>\n\n\n\n

Native or cross-platform for a custom Android app?<\/strong><\/h2>\n\n\n\n

As a mobile engineer, my default for a custom Android app that is genuinely Android-first is native Kotlin, because it gives you the fullest access to the platform, the best performance, the smoothest handling of the fragmentation and background constraints above, and immediate support for new Android features the day they ship. Cross-platform frameworks like Flutter and React Native are excellent and the right call when you need both Android and iOS from one codebase on a tight budget and timeline, and for a lot of business apps that tradeoff is worth it.<\/p>\n\n\n\n

The honest rule is this: if the app is Android-first, performance-sensitive, or leans heavily on platform-specific capabilities, go native Kotlin; if you need both platforms fast and the app is business-logic-heavy rather than platform-heavy, cross-platform is reasonable. The wrong move is picking cross-platform to save money and then fighting the framework for the Android-specific behavior you needed native for all along. If you are weighing this for a specific build, our enterprise mobile app guide<\/a> walks through the same native-versus-cross-platform reasoning in more depth.<\/p>\n\n\n\n

How much does custom Android app development cost?<\/strong><\/h2>\n\n\n\n

Cost scales with complexity, integrations, and device coverage far more than with the number of screens. Based on typical industry ranges and real engagements, here is the honest picture.<\/p>\n\n\n\n

Tier<\/th>What you get<\/th>Cost<\/th>Timeline<\/th><\/tr><\/thead>
Simple custom app<\/td>Focused feature set, minimal backend<\/td>$15,000 to $40,000<\/td>2 to 4 months<\/td><\/tr>
Mid-complexity<\/td>Real backend, integrations, custom UI<\/td>$40,000 to $100,000<\/td>4 to 7 months<\/td><\/tr>
Complex custom<\/td>Heavy integrations, scale, real-time features<\/td>$100,000 to $250,000+<\/td>7 to 12 months<\/td><\/tr>
Enterprise-grade<\/td>Compliance, multi-system, high scale<\/td>$250,000+<\/td>12+ months<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

<\/p>\n\n\n\n

The jump between tiers is rarely about more screens. It is about backend complexity, third-party and internal integrations, real-time features, and how many devices and OS versions you commit to supporting well. Budget for maintenance too, typically 15 to 20 percent of the build cost each year, because Android ships a new OS version annually and Play policy and security requirements keep moving.<\/p>\n\n\n\n

What does the custom Android development process look like?<\/strong><\/h2>\n\n\n\n
Phase<\/th>What happens<\/th><\/tr><\/thead>
Discovery<\/td>Define the real requirements, the target devices and OS versions, and integrations<\/td><\/tr>
Design<\/td>UX and UI, designed for a range of screen sizes from the start<\/td><\/tr>
Build<\/td>Kotlin and Compose sprints, with fragmentation and background constraints handled as they come<\/td><\/tr>
Test<\/td>Emulators plus real-device testing across the priority device and OS matrix<\/td><\/tr>
Launch<\/td>Play Store submission against current policies, staged rollout<\/td><\/tr>
Maintain<\/td>OS-version updates, Play policy changes, security patches, monitoring by device<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

<\/p>\n\n\n\n

The phase teams underinvest in is testing, because the emulator on a fast laptop hides exactly the device-specific problems that fragmentation creates. Real-device testing across the priority matrix is not optional on Android, it is where the quality actually comes from.<\/p>\n\n\n\n

A real-world scenario<\/strong><\/h2>\n\n\n\n

To make this concrete, picture a logistics company that wants a custom Android app for its warehouse and delivery staff, running on a mix of company-issued rugged Android devices and some older budget phones.<\/p>\n\n\n\n

A systematic reading of this guide sorts the build quickly. It is Android-first and runs on specific rugged hardware, so it goes native Kotlin rather than cross-platform, to get full control of the hardware and background behavior. Because the fleet includes older budget devices, the team uses real usage data to set a minimum supported Android version and tests on the actual rugged hardware, not just emulators, since those devices behave differently. <\/p>\n\n\n\n

Because staff scan and sync in areas with poor connectivity, the app is designed to work offline and sync in the background using the correct modern background-work mechanism rather than assuming it can run freely. And because it handles operational data, security and Play policy compliance are designed in from discovery. The result is a custom app that holds up on the messy real-world device mix, which is exactly what a template or a naive cross-platform build would have failed to do.<\/p>\n\n\n\n

Myths and common mistakes<\/strong><\/h2>\n\n\n\n

A few errors sink custom Android builds more often than any technical problem.<\/p>\n\n\n\n

The first myth is that custom always means expensive and slow. Custom means built for your needs, and a focused custom app can be modest in cost. The expense comes from complexity and integrations, not from the word custom itself.<\/p>\n\n\n\n

The second mistake is ignoring fragmentation until the support tickets arrive. If you do not decide which devices and OS versions you support and test on real hardware, you will ship bugs you never saw, and Android is unforgiving here.<\/p>\n\n\n\n

The third mistake is building on the old stack. An app built on Java and XML Views in 2026 is harder to maintain and hire for than one built on Kotlin and Compose, and you feel it every year the app lives.<\/p>\n\n\n\n

The fourth mistake is treating the emulator as sufficient testing. The emulator runs on a fast, clean machine and hides the exact device-specific issues that define Android quality. Real-device testing is where quality is earned.<\/p>\n\n\n\n

The honest caveat worth stating plainly: Android\u2019s openness and reach are its strength and its difficulty at the same time. The same freedom that lets you build almost anything also means an enormous device matrix to get right, and any guide that makes custom Android sound as simple as iOS is skipping the part that actually costs time. That is not a reason to avoid Android, it is a reason to build it properly.<\/p>\n\n\n\n

Why Mobilions<\/strong><\/h2>\n\n\n\n

Mobilions has been building custom software, mobile apps, and AI solutions since 2016. We have delivered more than 250 projects for over 100 clients across 20-plus countries, which means we have shipped custom Android apps on the modern stack, across the real device fragmentation this guide describes, not just written about it. <\/p>\n\n\n\n

When we scope a custom Android build, we start by defining the real device and OS matrix and the integrations, we build on Kotlin and Compose, and we treat fragmentation and Play compliance as design inputs rather than launch-day surprises. If you are planning a custom Android app and want to scope it honestly before committing a budget, or you need to hire Android developers<\/a> who have shipped on the modern stack, that is the conversation our team has with founders and businesses every week.<\/p>\n\n\n\n

Summary<\/strong><\/h2>\n\n\n\n

Custom android app development in 2026 means building for your specific business on a real, modern stack, Kotlin and Jetpack Compose, rather than assembling a template you will outgrow. Android\u2019s roughly 70 percent global reach is the opportunity, and its fragmentation across more than a thousand manufacturers and many OS versions is the real engineering challenge, one you handle by choosing your supported device and OS matrix deliberately and testing on real hardware. <\/p>\n\n\n\n

Design around Android\u2019s background limits, permissions, Play policies, and security from the start. Go native Kotlin when the app is Android-first or performance-sensitive, and cross-platform when you need both platforms fast. Budget by complexity, from about $15,000 for a simple app to well over $100,000 for a complex one. Get the stack and the fragmentation right and you have a custom app that actually works across the real Android world.<\/p>\n\n\n\n

Frequently asked questions<\/strong><\/h2>\n\n\n
\n
\n
\n

What is custom Android app development?<\/strong><\/h3>\n
\n\n

It is building an Android app from scratch in real code, tailored to a specific business, rather than assembling it from a template or no-code builder. Custom gives you full control over features, integrations, the codebase, and how the app scales, which matters when the app is core to the business rather than a simple brochure.<\/p>\n\n<\/div>\n<\/div>\n

\n

How much does custom Android app development cost?<\/strong><\/h3>\n
\n\n

It depends on complexity, integrations, and how many devices and OS versions you support. A simple custom app runs about $15,000 to $40,000, a mid-complexity app $40,000 to $100,000, and a complex one with heavy integrations $100,000 to $250,000 or more. Budget 15 to 20 percent of the build cost each year for maintenance.<\/p>\n\n<\/div>\n<\/div>\n

\n

How long does it take to build a custom Android app?<\/strong><\/h3>\n
\n\n

Roughly 2 to 4 months for a simple app, 4 to 7 months for a mid-complexity build, and 7 to 12 months or more for a complex custom app. The timeline scales with backend and integration complexity and the breadth of devices you support, more than with the number of screens.<\/p>\n\n<\/div>\n<\/div>\n

\n

What is the best tech stack for custom Android apps in 2026?<\/strong><\/h3>\n
\n\n

Kotlin as the language and Jetpack Compose as the UI toolkit, which Google recommends for new apps, along with a clear architecture like MVVM, Kotlin Coroutines for async work, Room for local data, and Hilt for dependency injection. Building on the old Java and XML View system in 2026 makes an app harder to maintain and hire for.<\/p>\n\n<\/div>\n<\/div>\n

\n

What is Android fragmentation and why does it matter?<\/strong><\/h3>\n
\n\n

Fragmentation is the wide diversity of Android devices: more than a thousand manufacturers, many screen sizes and chipsets, and many OS versions in active use. It matters because a feature can work on one device or version and break on another, so you pick which devices and versions to support and test on real hardware, not just emulators.<\/p>\n\n<\/div>\n<\/div>\n

\n

Should a custom Android app be native or cross-platform?<\/strong><\/h3>\n
\n\n

Go native Kotlin when the app is Android-first, performance-sensitive, or leans on platform-specific features, since native gives the fullest control and best handling of fragmentation and background limits. Choose cross-platform like Flutter or React Native when you need both Android and iOS from one codebase on a tighter budget and the app is business-logic-heavy rather than platform-heavy.<\/p>\n\n<\/div>\n<\/div>\n

\n

Why is Android development considered harder than iOS?<\/strong><\/h3>\n
\n\n

Mainly fragmentation. Android runs on a far wider range of devices and OS versions than iOS, where most active phones run one of the last couple of releases, so the testing matrix is much larger and device-specific bugs are more common. Android\u2019s stricter background-execution limits and open ecosystem add further considerations.<\/p>\n\n<\/div>\n<\/div>\n

\n

Do I need to support every Android version?<\/strong><\/h3>\n
\n\n

\u00a0No, and trying to is a mistake. Use real usage data for your audience to set a sensible minimum supported version and a priority device list, support those well, and let very old or rare configurations fall outside your matrix. Supporting everything equally wastes effort on devices your users do not have.<\/p>\n\n<\/div>\n<\/div>\n

\n

What are the main challenges in custom Android app development?<\/strong><\/h3>\n
\n\n

Device and OS fragmentation is the biggest, followed by stricter background-execution limits, granular permissions, strict and enforced Google Play policies, and security in an open ecosystem. Handling these as design inputs from the start, rather than discovering them after launch, is what separates a custom app that works from one that does not.<\/p>\n\n<\/div>\n<\/div>\n

\n

Should I hire a freelance Android developer or an agency?<\/strong><\/h3>\n
\n\n

A freelancer is cheaper and fine for a small, well-defined app or a single feature. An agency costs more but brings a full team, process, design, real-device testing, and continuity, which matters for a custom app you plan to grow. For a first serious custom Android build, a team usually beats coordinating several freelancers yourself.<\/p>\n\n<\/div>\n<\/div>\n

\n

How do I choose the right Android app developer?<\/strong><\/h3>\n
\n\n

Look at a portfolio of shipped Android apps, not just screenshots, and check that they build on the modern Kotlin and Jetpack Compose stack. Ask how they handle fragmentation, real-device testing, background limits, and Play policies. Start with a small paid task before a big commitment, and treat clear communication as the strongest signal.<\/p>\n\n<\/div>\n<\/div>\n

\n

Should I build my Android app in Kotlin or Flutter?<\/strong><\/h3>\n
\n\n

Choose Kotlin when the app is Android-first, performance-sensitive, or leans on platform-specific features, since native gives full control and immediate access to new Android capabilities. Choose Flutter when you need both Android and iOS from one codebase on a tighter budget and the app is business-logic-heavy. Match the tool to the app, not the trend.<\/p>\n\n<\/div>\n<\/div>\n

\n

Can AI or ChatGPT build my Android app?<\/strong><\/h3>\n
\n\n

AI tools can scaffold code, speed up development, and build simple prototypes, but they cannot deliver a production custom Android app on their own. Someone still has to own architecture, fragmentation, security, Play compliance, and the judgment calls AI gets wrong. Treat AI as a strong accelerator for a skilled developer, not a replacement for one.<\/p>\n\n<\/div>\n<\/div>\n

\n

How can I build a custom Android app on a budget?<\/strong><\/h3>\n
\n\n

Cut scope, not quality. Ship a focused first version that proves the core idea, support only the devices and Android versions your real users have rather than everything, and use cross-platform if you also need iOS cheaply. A tight custom app on the modern stack beats a bloated one, and you add features once demand is proven.<\/p>\n\n<\/div>\n<\/div>\n

\n

Do I need to publish a custom Android app on the Google Play Store?<\/strong><\/h3>\n
\n\n

Usually yes for a public app, and Play has strict, enforced policies on data, permissions, and target API levels, plus a review that can reject an update. Android also allows distribution outside the Play Store, which suits internal or enterprise apps. Either way, plan compliance from day one rather than as a launch-day checklist.<\/p>\n\n<\/div>\n<\/div>\n

\n

What is an MVP for a custom Android app, and where should I start?<\/strong><\/h3>\n
\n\n

Start by defining the real requirements, the priority devices and Android versions, and the integrations, then build the smallest version that delivers the core value on the modern Kotlin and Compose stack. Test on real hardware, not just an emulator. A focused MVP validates demand before you invest in the complex integrations and scale.<\/p>\n\n<\/div>\n<\/div>\n

\n

How much does it cost to maintain a custom Android app?<\/strong><\/h3>\n
\n\n

Typically 15 to 20 percent of the build cost per year, and more if the app is central to your business. Android ships a new OS version annually, Google raises the minimum target API level every year, and Play policy and security requirements keep moving, so budgeting for maintenance keeps your app from slowly aging out of the store.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Most guides on custom android app development treat the word \u201ccustom\u201d as filler and jump straight to a cost table. It is not filler. Custom means the app is built from scratch for your specific business, on a real engineering stack, instead of assembled from a template or a no-code builder that you will outgrow […]<\/p>\n","protected":false},"author":7,"featured_media":149,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[19],"tags":[65,54,64,66,63,67],"class_list":["post-146","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mobile","tag-android-app-development","tag-app-development-cost","tag-custom-app-development","tag-jetpack-compose","tag-kotlin","tag-native-android"],"_links":{"self":[{"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/posts\/146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/comments?post=146"}],"version-history":[{"count":2,"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/posts\/146\/revisions"}],"predecessor-version":[{"id":158,"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/posts\/146\/revisions\/158"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/media\/149"}],"wp:attachment":[{"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/media?parent=146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/categories?post=146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mobilions.com\/blog\/wp-json\/wp\/v2\/tags?post=146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}