I'm currently developing a mobile website with jquery mobile, not exactly responsive web design. I know I can develop the project in the browser on my desktop PC with some plugins or use some online services or simulators available. But I'm not sure if I missing something really important for test.
Example:
touch/swype events or viewport rotation.
Is necessary purchase some physical devices (smartphone/tablets) to develop/test the project? Why?
Intro
First don't let anyone tell you it is not necessary to purchase a real devices for a test purpose. I will tell you why from an Android perspective, same thing, just in a much smaller manner also goes for iOS development.
Good sides of an emulator testing
It is free, you only need a computer which will run your emulator.
You can test your applications in different cases (different screen resolutions, different OS versions)
Faster I/O and network operations but this is not so much a good point if you calculate how much everything else is slow.
Bad sides
It is slooooooooow, if you never tried to use it you can comprehend how slow it is (iOS emulator is fast like hell in a comparison). It doesn't matter if you have a top of a line hardware PC or Mac it is just that slow.
Emulator is simply to darn buggy, there will be a lot of times when application will work just fine on a read device and it will brake on an emulator.
This also goes other way around, sometimes application will work just fine on an emulator but will brake on a real device, in some case it will not work at all or it will not work on some devices. This is usually a case when working with hybrid applications. for some reason Android web view acts differently on real devices and on an emulator.
Emulator simply don't have some functionalities to interact with a hardware nor it can successfully emulate it. Hardware connection it can emulate even don't work correctly sometimes.
I have talked about how slow it is (because of a converting ARM bytecodes to x86 ones on the fly) but from a graphics standpoint it tends to be even slower so don't expect to do any game development on it.
Real devices comes with much more preinstalled software which may slower your application or in some ways enhance its functionalities.
Real world GPS testing is out of a question
Final notes
If you are intending to work with iOS only emulator can be used to do much of a development. Sheer lack of different screens sizes and hardware diversity makes it a perfect platform for a test purposes. Android on the other hand is completely different story, its emulator is simply useless for test purposes. I have several real Android devices, ranging from Android 2.1 + , different screen sizes and finally hardware architecture. You don't need to believe me but everything I mentioned play a significant role while testing Android applications.
If your main concern is testing your jQuery Mobile application I would still advise you a use of a real device in case of Android while in case of iOS you can successfully use emulator. Android is problematic because transition effects are to darn slow and that includes everything else that requires animations. Swipe will not be a problem and I can vouch it works just fine. Second real problem is a device rotation. jQuery Mobile sometimes can have a problem with it, mostly when used with non responsive 3rd party jQuery plugins (carousels, sliders ....). Third problem is mentioned in my list of bad sides, basically web view used in a emulator acts different then one in a real phone so sometimes you will see one thing in your real device and one thing in your emulator.
It is not necessary to purchase such a device.
For Android there is an emulator provided by the Android Development Kit (ADK). You can use it to configure multiple emulated devices with defferent screen sizes, etc. to test for multiple resolutions and Android (browser) versions.
[edit] Though to really test it for iphones you would need that emulator too I suppose, to make sure the website is correctly displayed in the provided browser.
[edit 2] To test "real" smartphone apps (not webapps), it is better to have a real device at hand.
This very much depends to which level you want to test it before you are happy to hand it over for the usage. After you do that and someone reports a defect, will you be able to see where is the problem (if it works on your PC)?
The development itself can be done in your browser, you can even simluate swipe events by dragging mouse. You don't even need any simulators, you can just make chrome window smaller (most of the devices are using some version of webkit, same as chrome).
However, once it comes to testing, I wouldn't feel great if I didn't know how it looks on the device itself. So I think having at least one device (ideally two with different OS and resolution) is always beneficial.
I would also be unsatisfied if I was working on something of which I could not see the result :)
As a mobile app developer on all platforms, I am interested to know if it is worth it to write BlackBerry apps for the older OS now that BBX is coming out. I heard the new OS will have an Android player that will supposedly run Android apps on it. It seems that any apps written for the older OS won't be compatible with the BBX OS. Also, is using WebWorks a viable option? What do you guys think?
The road map ahead for developing for BBX announced at DevCon is:
HTML5, WebWorks, Adobe products (Air)
Native C/C++
Android Applications repackaged to run on the Android Player
BlackBerry OS is deprecated after OS 7. That said however, there are currently 70 million (according to RIM) BlackBerry smartphones in use, none of which will likely ever support BBX. RIM will continue to support those devices and the development environments for them. If you only want to work in one environment, and want to support the greatest number of devices, both BlackBerry OS and BBX, then WebWorks is the way to go. If you only want to support the PlayBook and BBX devices then you can use any of the approaches listed above. If you can't do what you want in WebWorks, or want to support devices prior to the introduction of WebWorks support then you will have to use the BlackBerry Java Environment.
At some point in every product line you will come to the end of useful life of a product and, as a developer, have to face moving on into the future. It is going to be worth while developing for BlackBerry OS as long as doing so helps you achieve your goals, what ever they are. So you have to look at your target market and decide if it includes those users who will be carrying BB OS devices, for probably at least the next 3 years, or not.
That's correct, legacy BlackBerry code will be useless:
DevCon update: BB-Java is dead, no java support for QNX.
By the way, the Android player will have several limitations too. Your best bet is C++ for BBX. Luckily, BlackBerry market share is declining and there's not a single BBX device out there yet.
Update: New BlackBerry 10 (as BBX is called now) phones have just been released. Here are the final dev options:
Native C++ API (optional libraries are available)
Android API, partial support
Adobe AIR API, partial support
HTML5 API, partial support
I'm planning to create an app for blackberry. The Android and iPhone Versions are almost done. Next on the list is the blackberry one.
So my question is: how good are the simulators? Do I need a real device to test? Which one would you recommend?
It is unlikely you'll be able to create a bugless app without a real device. However totally ignoring simulators would also be a mistake. Simulators are quite good, because they allow to test a substantial part of features on a wide range of device models/OS versions. It would be quite expensive to have a dozen of real devices. :)
Usual points to bear in mind while working on simulators:
real devices are slower in times.
simulators do not support permissions (simulators act as if permissions are always granted regardless of what you actually see).
real device may not support the same type of network transport that your simulator has (TCP, WIFI, BES).
big wireless providers (e.g. Verizon) usually install a slightly customized version of BB OS on their devices, and sometimes it results in a different behaviour (or even bugs).
I've had fairly good luck with the simulators. I've been using the Storm, and I have a real curve. I have a colleague with a real storm so I run everything by him as well.
There have only been 2 times that having a real device has helped me. 1. Making sure I had my install files correct. Since Eclipse just copies them out to the simulator it took me 2 attempts on a real device.
and 2. When testing creating & using a database on the sim card. I got about 95% there on the simulator, and the other 5% was really just verification.
That said, which one depends on what version you're writing for. Storm and some curves are 5.0 (and can be upgraded to 6.0) The Torch is only 6.0
Blackberry simulators are really good
They are exact replicas of the devices
I have worked with storm and also the torch devices
I have faced problems during the connections to the internet
and while using the SD cards (SQLite databases)
Getting images from the SD Card which is not possible from the simulator
If you are developing an application which needs the basic UI components and the native blackberry components, simulators are fine
But if you are really developing something out of the box device is a must
It would be more better if an app can be tested in the device before rolling out
Try your luck
Thank you.
The Blackberry simulators are fine. I believe they are built using the same code as actual devices, so they are pretty much identical to real devices. The only thing that makes a difference is the software that they run.
The simulators will provide you with almost all the same functionality with the exception of things like GPS. I believe I've used an image from an SD card before using the simulator as well...
As far as I know, simulators are set at a specific OS version, whereas in the real world there are tons of different OS versions being used (minor revisions). There have been cases where a feature has worked on the simulator but once it was built and launched on the device, the device shows something different. So if you want to get your app tested, you should test on your TARGET device and OS on simulator and real device.
I develop and test applications for BlackBerry 4.5, 4.6, 4.7 and 5.0, but have done testing only with the respective simulators. Now I am about to buy a new BlackBerry device to test my applications better in a real scenario.
Can anyone suggest which device suits my needs?
Hi
I'm not sure about this model but i do know that in other cellphones you need to change the software version every time. Because you mentioned that you want to build apps for different OS versions.
You should try to locate a device that is the easiest one to change OS version and be able to downgrade and upgrade without any errors.
thanks
The current BB devices on the market are generally 5.x and up. You have to define a minimum version you'll support. As long as your app doesn't do too much hackery JDE versions are upwardly compatible.
Simulators generally model real devices well except for the networking. You see some differences especially GSM vs. CDMA devices. Ex. if you ask for the device's phone number (in the NAMP) it may or may not start with a 1.
If you're on a budget or decide to buy multiple devices you might want to try Curve 8520 - it's one of the cheaper new models, comes with BlackBerry OS 4.6 upgradable to 5.0, but still has most of the functionality you might need, except for the GPS.
Additionally it has one of the lower resolutions RIM has to offer (320x240), so if your apps are UI intensive you can see if they work well with entry level models.
Hope it's of any help.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I've heard that you need to get a Mac if you want to develop iPhone apps. Is this true?
Is it possible to develop iPhone apps using Linux? If yes, what do I need and where do I download the necessary tools?
To provide a differing response, I'm running OS X and Xcode on a virtualised (VMware) machine on Linux. CPU is a Core2Quad (Q8800), and it is perfectly fast. I found a prebuilt VM online (I'll leave it to you to find)
Xcode/iPhone development works perfectly, as does debugging via USB to the phone itself.
It actually surprised me a lot - but I've had no issues at all.
The answer to this really depends on whether or not you want to develop apps that are then distributed through the iPhone store. If you don't, and don't mind developing for the "jailbroken" iPhone crowd - then it's possible to develop from Linux.
Check this chap's page for a comprehensive (if a little complex) guide on what to do :
http://www.saurik.com/id/4
It seems to be true so far. The only SDK available from Apple only targets the macOS environment. I've been upset about that, but I'm looking into buying a mac now, just to do iPhone development. I really dislike what they are doing, and I hope a good SDK come out for other environments, such as Linux and Windows.
Obstacles regarding the SDK:
The iPhone SDK and free software: not a match
Apple's recently released a software development kit (SDK) for the iPhone, but if you were hoping to port or develop original open source software with it, the news isn't good. Code signing and nondisclosure conditions make free software a no-go.
The SDK itself is a free download, with which you can write programs and run them on a software simulator. But in order to actually release software you've written, you must enroll in the iPhone Developer Program -- a step separate from downloading the SDK, and one that requires Apple's approval.
I think it's rather elitist for them to think only macOS users are good enough to write programs for their phone, and the fact you need to buy a $100 license if you want to publish your stuff, really makes it more difficult for the hobbyist programmer. Though, if that's what you need to do, I'm planning on jumping through their hoops; I'd really like to get some stuff developed on my iPhone.
There used to be a project dedicated to solve this defect: iphone-dev
The goal of the iphone-dev project is to create a free, portable, high quality toolchain to enable development for the Apple iPhone and other embedded devices based on the ARM/Darwin platform.
Regarding the alternative tool chain, Saurik's site is useful but for latest firmware development he indicates building on the iPhone itself and stays clear of indicating that you may need to copy necessary iPhone firmware files to your Linux environment. It's not impossible, but just requires additional work, especially for signing the code (there are open alternative solutions out there as well).
Also, take a look at other guides (for the same tool chain) that approach it more methodically.
I'd suggest to still do the final build and code signing and packaging in XCode (which may mean borrowing someone's Mac) in case you run into problems when submitting the application to Apple. Using the alternative tool chain opens up (at least on the Mac) the possibility of using other IDEs other than XCode for developing the application and again resorting to XCode for the deployment and testing with the simulator.
Of course if you do get the code signing / certificate generation working from the command line outside of XCode then you can install a certificate on your actual iPhone and test there (installing the app via iTunes w/your certificate).
The only way I know of doing development in Linux for the iPhone would be to install Vmware and work on getting OS X running in a virtual machine. With that said there are some "legal" concerns in doing that. It is reported that OS X Server can be virtualized but as far as the development story on that I don't know.
If you are truly serious, that's the what I'd investigate.
Good luck.
You can use Tersus (open source), and it lets you export the app as an Xcode project.
You might be able to write code on a Linux box that will eventually find itself on an iPhone or iPad, but ultimately you would need a Mac to test or deploy the code to the iPhone or to submit it to the App store. So ultimately you need a Mac, so you might as well do the work on the Mac too, with all the tools that Apple provide. There are alternatives to Xcode & Objective-C, such as Monotouch - but these utilize the Apple tools too.
You can with some work run OS X in a VM on Linux. However I should point out that this will break the OSX license agreement, even if you buy the copy of OSX - as it is only licensed to run on Apple hardware.
Sorry to give you this news - the ecosystem around the iPhone/iPad is very tightly controlled.
EDIT: One major exception to this is writing a web app for the iPhone. There are some excellent web apps for the iPhone which are almost as good as user experience as a native app. However I did interpret your question to be about native app development. Web apps, although the user can create an icon for launching them - are still 'second class' citizens.
I've had success building iOS apps on linux using the iOS clang toolchain by cjacker. Basically it consists of the upstream clang and llvm tools from your linux distro, a linux port of apple's linker and some extra tools to help simplify the build process (such as converting xcode projects to Makefile format).
It does take a few steps to install, but you're a software developer so you'd be used to that. I posted an up to date howto for Debian 7 (Wheezy) online:
https://rogerkeays.com/how-to-build-an-ios-toolchain-for-linux-debian-7
Otherwise you want to go with the generic instructions which are a little older:
http://code.google.com/p/ios-toolchain-based-on-clang-for-linux/wiki/HowTo_en
Good luck.
There's a framework called Rhodes.
The concept is based on Ruby on Rails and you develop your mobile app in Ruby and HTML, and you can write your code in a Linux environment. You can then create an account at Rhohub, where you add the code (through GitHub), and it allows you to compile it for iPhone, Blackberry, Android, Windows Mobile and Symbian, all off the same code. You don't have to code in Objective-C for iPhone, nor Java for Android, etc. It does the conversions for you. All you need to do is stick to the Rules for creating an iPhone application (or the Phone's you want to develop for) so it can be accepted at iTunes (or the equivalent market).
This will allow you to add the app to iTunes as well.
I have not found any emulators, however, which means that to test your app you need to put it on an iPhone, which is a mission.
I am using this option as I want to create apps for all phones and I use Ruby on Rails already. If you just want to make an app for an iPhone, then invest in a Mac.
Hope this helps.
You're right non-jailbroken phones are limited to Apple's App store and Apple "has the right" to enforce whatever rule, it's totally nonfree territory.
However while developing, one won't have to deal with Apple at all. You can use e.g. rsync to upload the code to the device and test it.
To a certain extent, yes, it is possible. You can type Objective-C code and set up your projects. You can even test the C and C++ parts of your code with gcc.
What you cannot do:
Use Interface Builder to set up your interface, as it's Mac-only. (Not required, but recommended.)
Compile code that uses Apple's Cocoa classes - they don't exist on Linux.
Test code in the Simulator - there isn't one for Linux.
Compile code for real devices or for the App Store - all this requires tools that Apple only provides for OS X.
You need to get mac for it. There are several tool chains available (like win-chain) that actually lets you write and build i Phone applications on windows. There are several associated tutorials to build the Objective C code on Windows. But there is a problem, the apps hence developed will work on Jail broken i Phones only.
We’ve seen few hacks to get over that and make it to App Store, but as Apple keeps on updating SDKs, tool chains need regular updates. It’s a hassle to make it up all the time.If you want to get ready app you can also take help from arcapps its launches apps at a reasonable price.
iphone app development
I did an attempt to port cocos2d-iphone to GNUstep so that you can Develop game based on cocos2d. However for publishing you need a mac. cocos2d-GNUstep.
I would recommend getting a mac because the ios simulator is amazing for testing in the early stages of an app. But I do know of a small company we work with that develops using Unity so they don't need a load of macs. That way they only need one mac for the office and that's just to compile the final build. It also means it works on android but it really depends on what your building because it's a games engine. You may want to look into web apps using frameworks like Sencha Touch Mobile
Unity: http://unity3d.com/
Sencha Touch: http://www.sencha.com/products/touch/
If you value your time, buy a Mac! I don't know enough about Linux development options to offer a viable solution, but it seems the proposed methods involve some pretty roundabout work. If you plan on seriously writing and selling iPhone apps, I think you could easily recoup the cost of a Mac Mini or Macbook. :-)
You will never get your app approved by Apple if it is not developed using Xcode. Never. And if you do hack the SDK to develop on Linux and Apple finds out, don't be surprised when you are served. I am a member of the ADC and the iPhone developer program. Trust, Apple is VERY serious about this.
Don't take the risk, Buy a Macbook or Mac mini (yes a mini can run Xcode - though slowly - boost the RAM if you go with the mini). Also, while I've seen OS X hacked to run on VMware I've never seen anyone running Xcode on VM. So good luck. And I'd check the EULA before you go through the trouble.
PS: After reading the above, yes I agree If you do hack the SDK and develop on Linux at least do the final packaging on a Mac. And submit it via a Mac. Apple doesn't run through the code line by line so i doubt they'd catch that. But man, that's a lot of if's and work. Be fun to do though. :)