MechDome is a Developer Tool that Automatically Converts Android Apps into iOS and OSX Apps

Cross-platform development has presented a major challenge for most independent developers for many years. Quite often, it’s simply too much of an time and resource investment to learn a new programming language in order to port your app over to another platform.

For years, this fact of resource allocation is what has pushed many developers to primarily focus their efforts on iOS, due to the more lucrative market. Thanks to projects such as Xamarin, however, developers who are familiar with C# have been able to push their projects across iOS, Android, and Windows Mobile. But Android developers are most familiar with writing in Java, so using Xamarin would require a developer to familiarize themselves with a new language and build platform. We’ve covered one project aimed at bridging the gap between mobile operating systems by providing a cross-development platform for Java developers – Intel’s Multi-OS Engine – but there’s no telling where that project is headed. That’s where MechDome comes in.

MechDome is a start-up company based in California and incorporated in January that has developed a conversion tool to automatically create native iOS and OS X apps from your Android app. No need to learn how to use a new IDE or API. All you need to do is send an APK file to MechDome (no need to send them your source code), and the fully automated tool will compile a standalone binary in seconds for iOS and OS X that the developer can then distribute on Apple’s App Store. We sat down in an interview with MechDome’s founder and CEO, Mario Kosmiskas, to see a demonstration of the tool in action – and it works. Although there are some limitations due to fundamental differences between how iOS and Android operate (which we’ll discuss below), the tool has already produced a few live apps on the Apple App Store such as the open-source Reddit client RedReader and an open-source Sudoku client to prove it works.

Android Apps on iOS with MechDome

The stated goal of MechDome is to allow developers to convert an unmodified Android app into a native iOS or OS X app. Compared to technologies such as Intel’s Multi-OS Engine or Xamarin, an Android developer does not need to know how to bind an Objective-C library because the tool will handle that for you. Nor is there any need to use a UI builder to modify your Android app, as MechDome handles converting all Android UI elements. Yes, even Android tablet apps translate nicely into a format suitable for iPads.

RedReader on iOS


RedReader on Android

MechDome’s biggest promise is that the converted Android app will function in a manner that users of the target OS will be familiar with. For instance, the Android share menu will be replaced with the native share sheet in iOS, and will include the ability to use AirDrop if applicable. Apps that post notifications in Android will instead display a notification in iOS’s Notification Center. Certain intents such as opening a camera on Android will indeed open the camera on the iOS device, and URL intents on Android will call Safari on iOS. Content providers on Android that access contacts or the calendar will instead access the relevant iOS or OS X databases for this information.

Android UI Elements on iOS
Slide-In Menu
Converted Share Functionality
Text Input
Posting Notifications

In general though, all hardware functionality required for the use of an Android app will be mapped directly to use the relevant hardware in iOS. Software functions, though, can be split into 3 distinct categories: 1) functionality that doesn’t exist on iOS (such as the toast message) will be implemented directly, 2) functionality that exists on both iOS and Android are replaced with the relevant iOS method, and 3) functionality that exists on iOS but not on Android (such as Apple’s 3D Touch library) cannot be converted but can be implemented through the use of a library. Most activities, views, services, toasts, and basic content providers should be convertible from Android to iOS, according to MechDome’s founder.

But as mentioned previously, there are indeed some limitations to this tool that are imposed by the nature of how iOS works. One of the biggest challenges facing an Android developer looking to convert his or her app to iOS is how to handle a background service. iOS is much more stringent with when and what kinds of background services that third-party applications can run, for better or worse. Furthermore, the rich intent system present in Android that allows for inter-app communication is largely absent on iOS. Finally, the Google Play Services API is currently not supported, so any app relying on Google services will not function. Thus, developers will be mostly limited to functionality that is accessed directly by manual user input, which should not pose a significant problem for most games or apps.

MechDome In Use
In a private demo, the tool does indeed seem to function as advertised. Mr. Kosmiskas demonstrated compiling several fully functional Android apps into working iOS and OSX apps. Toast notifications, notifications in the Notification Center, webview, location access, text input, and general functionality of UI elements all worked in demo. The AOSP calculator running on iOS looked and functioned exactly as it does on any Android device.


Updating an application and re-compiling it for iOS was also shown, and the process fairly simple. The developer, in this case Mr. Kosmiskas, demonstrated changing a text box to display “XDA-Developers” in Android Studio. He then exported the app, generated a signed APK, and compiled the iOS and OS X binaries in seconds from the MechDome server. When the iOS app was started using an emulator, the changes made in Android Studio were present.

Currently, MechDome is undergoing a free public beta program. Developers can register their app on the MechDome website to receive an invite to test converting their Android app. No pricing information has yet been unveiled for the service, unfortunately. Still, it’s an interesting project to stay on the lookout for if you’re an Android developer looking to eventually make waves in Apple’s ecosystem without having to expend much effort of your own.

from xda-developers

Google Reportedly Wants OEMs to Integrate Google Home in Products

October 4th is going to be a big day for the Mountain View internet giant. It’s all but confirmed to be the day Google officially announces the upcoming Pixel and Pixel XL smartphones. We’ve seen mock-ups created, the the front display assembly leaked, photos showing the front and back of the devices, and software details about how they will have 2 of each partition and how that could allow community developers to do a number of unique things with custom software.

It’s fair to say the Pixel and Pixel XL have not been shy over the last couple of months. We’re looking forward to seeing these two devices officially announced next week, but rumor has it that smartphones won’t be the only thing Google unveils on October 4th. If true, we could see Google announcing hardware products like the Chromecast dongle that can support Ultra HD video, the Daydream View VR headset, and Google Home.

You can think of Google Home as their way to compete with the Amazon Echo. A standalone device that allows you to access your entertainment (like playing songs and playlists), manage your everyday tasks (like setting reminders, making reservations, controlling your lights and thermostat), and having access to Google search all with just your voice. It was originally thought that Google would be the sole manufacturer of this device, but a new report says otherwise.

Variety is reporting that Google is wanting other OEMs to integrate Google Home into their own products. At first it seemed like this meant something similar to how they did their OnHub router where multiple manufacturers could make their own, but it could go beyond that. At a closed door meeting with Google, it’s said that Google wants other OEMs to utilize Google Home like they have been with Google Cast. The report also says that Google might be displaying “aggressive muscle-flexing” in its negotiation by telling manufacturers that they’d have to incorporate the service if they want their products to be able to use Chromecast at all.

Either way, we could see a number of products like smart TVs, soundbars, Bluetooth speakers, and more have Google Home baked right into the product and as early as next summer.

Source: Variety

from xda-developers

Qualcomm is Reportedly in Talks to Acquire NXP Semiconductor

Qualcomm’s financial standing seemed to have started going slightly down hill when Samsung opted for their own Exynos chipset over the traditional Snapdragon variant in select markets last year. The company had to revise their sales targets for the entire year because of this and while they did beat analyst expectations in Q3 of 2015, revenues were still down $7.1 billion during the same quarter the year before.

The company saw profits increase during Q1 of this year, but overall revenue was still down 19% YoY due to a fall in shipments. Qualcomm losing some of its modem business to Intel puts pressure on them too. So we can see Qualcomm hasn’t had the best track record lately (more specifically, last year), but a new report suggests they can even this out with a possible acquisition. The Wall Street Journal is reporting that Qualcomm is looking to acquire NXP Semiconductor for upwards of $30 billion.

Less than a year ago, NXP had acquired Freescale Semiconductor for a cool $12 billion that made the company the “the world’s top maker of automotive electronics.” See, while NXP does offer some ARM SoCs, they are focused more on the low-power components for integrated devices. The company sells a number of automobile products like temperature sensors and power management controllers.

During the first two quarters of this year, NPX saw over a 50% increase in revenue growth compared to the same quarter a year before. So while we could see some overlap here with NXP’s SoC business, this acquisition could be more about expanding away from smartphones and diving into other markets. This type of diversity would allow Qualcomm to still thrive if they happen to have another slip up like they did with the Snapdragon 810, and at the very least it allows Qualcomm to expand without as much risk by acquiring a repertoire of established designs.

Source: The Wall Street Journal

from xda-developers

LeEco Sends Out Press Invites for an Event in the US

LeEco, formerly known as LeTV, is a massive Chinese conglomerate that has their hand in all sorts of industries. The company deals with music, sports, smart TVs, cloud computing, driverless cars, and has made a big splash in China and India with their smartphone business. Much like Xiaomi, LeEco’s smartphones are priced very competitively and with impressive build quality for the price you pay.

The LeEco Le Max 2 was already a popular phone for the company in India, and they just gave it a temporary price cut, down to Rs. 17,999 (~$270USD). It is hard for OEMs to compete with LeEco when it comes to price, and lately we’ve seen the company start to plan an expansion into the United States. They opened up their first United States headquarters in San Jose earlier this year, then bought over 48 acres of land from Yahoo a month later, and finally confirmed something big for the US this fall season.

At the time they announced their fall surprise for the United States, LeEco had already hired 400 employees. The company says they they are on track to grow this number to 1,000 before the end of the year so it seems obvious they are planning for something big in the states. Now, LeEco has started to send out press invites to various technology publications for an upcoming event that will take place in San Francisco on October 19th.

They have yet to confirm exactly what this event will be about, but many are speculating it will be the first time their products will officially be sold in the country, and some reports claim they might be bringing their services too. But again, LeEco is involved in a number of industries so it’s hard to pinpoint exactly what they’re planning. We would like to think they will announce plans to sell their smartphones in the US (and we believe it makes the most sense, given other similarly competitive companies are doing the same lately), but this could be about smart TVs, smart bikes, etcetera. We’ll just have to wait a few weeks and see how things turn out.

Source: TechnoBuffalo

from xda-developers

More than a Meme: Google uses to Benchmark Nexus Devices

Digging around in AOSP is a great way to make new discoveries about Android, and this time we’ve come across something rather hilarious. For some time, users have reported that the technology website provided slow performance on mobile devices.

Now to their credit, their website performance has improved over time in my experience. Plus, it’s not as if other sites (including our own) don’t have issues we can strive to work on, but nevertheless I found it quite amusing that in its official set of workload benchmarks, Google decided to use The Verge in their testing.

Android Workload Automation

Workload Automation (WA) is a framework developed by ARM for collecting performance data on Android devices by executing a suite of many repeatable workloads. Google benchmarks performance on their devices by doing many of these workload tests and collecting a summary of power usage, which they then import into a spreadsheet to see how their optimizations have improved performance over time. The company picks and chooses which apps to include in its test suite, but in general they limit themselves to most of the popular Google apps. That’s the gist of how it works, but we’ll show the evidence from source code and describe the test suites in more detail so you can get a better picture of what automated tests Google does to measure performance.

Within AOSP, there is a directory dedicated to the workload automation tests. The apps that are used for testing are defined in, and generally fall under one of two categories: default, pre-installed Google App or third-party web browser. One benchmark app stands out from the rest, and it’s com.BrueComputing.SunTemple/com.epicgames.ue4.GameActivity which I assume refers to the BrueBench ST Reviewer benchmark which is based on the Unreal Engine 4.

# default activities. Can dynamically generate with -g.

These activities are launched via the ADB command line with the following Systrace options to measure app performance:

dflttracecategories="gfx input view am rs power sched freq idle load memreclaim"

The Chrome app in particular is launched with a flag to load The Verge:


As for why the test seems to differ for the volantis (Nexus 9), I’m not exactly sure. Anyways, as for what tests this Chrome-activity-with-The-Verge actually goes through, we can determine by looking at the source code of the workload automation tests.

Test Suites

First up, there’s the test, which Google states works as such:

# Script to start a set of apps in order and then in each iteration
# switch the focus to each one. For each iteration, the time to start
# the app is reported as measured using atrace events and via am ThisTime.
# The output also reports if applications are restarted (eg, killed by
# LMK since previous iteration) or if there were any direct reclaim
# events.

Next, there’s the test, which works like this:

# Script to start a set of apps, switch to recents and fling it back and forth.
# For each iteration, Total frames and janky frames are reported.

And then there’s chromefling.shwhich tests Chrome’s performance rather simply:

# Script to start 3 chrome tabs, fling each of them, repeat
# For each iteration, Total frames and janky frames are reported.

Another amusing test in the Workload Automation suite, although unrelated to The Verge, is the performance test which measures UI jank

# Script to play a john oliver youtube video N times.
# For each iteration, Total frames and janky frames are reported.
# Options are described below.
searchText="last week tonight with john oliver: online harassment"

Finally, each of these tests are used to measure real world power usage by cycling through them for a certain amount of time, as defined in

# Script to gather perf and perf/watt data for several workloads
# Setup:
# - device connected to monsoon with USB passthrough enabled
# - network enabled (baseline will be measured and subtracted
# from results) (network needed for chrome, youtube tests)
# - the device is rebooted after each test (can be inhibited
# with "-r 0")
# Default behavior is to run each of the known workloads for
# 30 minutes gathering both performance and power data.

Google can then collect these data using and import them into a spreadsheet:

# print summary of output generated by
# default results directories are <device>-<date>[-experiment]. By default
# match any device and the year 201*.
# Examples:
# - show output for all bullhead tests in july 2015:
# ./ -r "bh-201507*"
# - generate CSV file for import into spreadsheet:
# ./ -o csv

These are all fairly common real-world UI performance tests, not unlike the kinds you would see in our own testing. It appears that the change to load The Verge’s homepage when opening Chrome was rather recent, as before last year Google would only open a new tab in Chrome during these tests. A change made in May 28th, 2015 introduced the use of The Verge when testing Chrome, however. As amusing as it is that Google is using The Verge of all places when performing Workload Automation testing, keep in mind that this doesn’t mean The Verge is the worst offender out there for web performance.

Far from it, in fact, as many other webpages suffer from mediocre performance thanks to the proliferation of more and more ads to compensate for the rise of ad-blockers. Indeed, it’s most likely that the decision to use The Verge was simply one out of convenience, given how tech savvy the average Googler is and the inside joke among many enthusiasts regarding The Verge’s webpage performance.

from xda-developers

New Android Wear 2.0 Preview with Smart Replies, Watch App Store — Main Release Delayed until 2017

There are both good and bad news for Android Wear owners today — well, the good news are mostly reserved for a few lucky watch owners. But in short, a new Android Wear 2.0 Preview is available for download and flashing.

The new Developer Preview 3 brings some rather big additions, including the additions of a Google Play Store on Android Wear. This allows you to easily find and install apps directly on the watch, which synergies perfectly with the watch-only app capabilities of Android Wear 2.0 You can browse recommended apps in the home view, search for apps, and then install them on your watch, as well as update applications. This makes app management easier, and you can install the watch-app portion of a service so you don’t need both the phone app and watch app, as the former are no longer necessary. Developers can now build and publish watch-only applications!

An on-watch store might sound clunky, but Google surveyed developers and ran studies that concluded users repeatedly looked for a way to discover new applications right from the watch. Developers can publish their apps on the Play Store for Android Wear by following these steps, making sure the Wear 2.0 apps set minSdkVersion to 24 or higher, use the runtime permissions model, and are uploaded via multi-APK using the Play Developer Console.

Android Wear 2.0 Dev Preview 3

There are also a few new, useful features and optimizations, with a prominent one being improvements to complications for developers, a new UI component for developers to optimize vertical lists for round displays, and Smart Reply. That’s right, Android Wear now generates Smart Reply responses for MessagingStyle notifications. These are generated by an on-watch machine learning model based on the context of the notification (no data is uploaded to the cloud to generate responses). Sadly, said notification style with images posted by standalone apps don’t show images in the notification (bug), and there is no support for notification groups.

Android Wear 2.0 Dev Preview 3

You’ll need to flash the system image onto your watch and download the beta version of the Android Wear app on your device. Developers can also use the emulator to test their applications if they don’t have a watch to test on. Hopefully you’ll enjoy this preview, because the real deal is not coming for a while: Google now says that they’ve decided to continue the preview program into early 2017, and that the first watches will receive Android Wear 2.0 around that date. This means that the Android Wear 2.0 update won’t come until next year for most of us, at the earliest. This also likely means we won’t see Pixel watches this year.

Google has not mentioned any official reason for this delay in the release timeline, except the receipt of feedback from the developer community. And the delay of Android Wear 2.0 likely isn’t good news for smartwatch OEMs either, as they would now have to settle with either the existing stable release, or question the future of the platform entirely. There are no new successors to existing smartwatches coming in from the big names, and even Huawei is in talks to jump ship to Tizen. Existing stakeholders who have invested in new smartwatches this year, like ASUS with its ZenWatch 3, are also not likely to be happy with how the timeline has taken a turn for the worse. All in all, considering the current position of Android Wear in the market in light of its competition, the delay in release must have been a very strong decision to take, just before the upcoming holiday season.

What are your thoughts on the delay in Android Wear 2.0 release? Also, how was your experience with the Dev Previews of Android Wear 2.0 so far? Let us know in the comments below!

from xda-developers

What Features Do You Want on Google Apps on Android?

Google Apps on Android are a love-hate affair. Average consumers find the pre-loaded set of Google Apps to fit within their requirements enough to not worry about alternatives. But on the other hand, the apps themselves are not the best examples of how to create guidelines, or how to make apps either.

The previous statement becomes clearer when you expand your scope to look at Google Apps on other ecosystems, like iOS or on desktop platforms like Chrome OS. Apps made by Google themselves on these platforms feature a different design, and often offer functionality that the Android app gets days, weeks and months later (looking at you, Hangouts). Some Android apps, like Youtube, are missing useful features present on desktop. So we ask you,

What Features do Google Apps on Android sorely lack, when compared to the same set of Google Apps on other platforms? Which was the most frustrating discrepancy you noticed when you switched from using Google Apps on Android to other platforms?

Let us know in the comments below!

from xda-developers

Samsung is Waiting to See How the VR Market Develops

Samsung is satisfied with the progress they’ve made in the mobile VR space thanks to the Gear VR for the Galaxy S and Galaxy Note series. However, they do realize that the display technology isn’t quite there yet and this is why they’ve been holding back on releasing a standalone VR headset. The company also says VR is at the peak of its hype phase, and they want to wait and see if the market matures.

In case you don’t remember, Samsung confirmed they were working on a standalone VR headset back in April of this year. As with most products that big companies work on, not all of them will see the light of day. A lot of them are worked on to help progress the technology to a level where consumers will he happy with it. This is what we’re currently seeing at Samsung with a VR headset that doesn’t require a smartphone.

Samsung believes display technology needs to advance to at least twice the pixel density that we have in smartphones today. So it looks like the company is waiting and seeing how the experience of a standalone VR headset will be with Ultra HD display panels. Samsung’s President & Chief Strategy Officer, Young Sohn, says this could be an incentive for the company to advance the technology faster, but it would cost them at least $5 to $10 billion to do so and develop a 10K mobile display.

As as we mentioned earlier, they just don’t know if the VR market is worth that type of investment right now. They are willing to do so if the customers prove they are willing to buy into this technology, but they are worried the market will stagnate after the hype dies down. Sohn says it’s “a bit of a chicken and egg problem right now,” and would rather just wait and see how the market evolves before taking a big leap like that.

Source: TechCrunch

from xda-developers