Every now and then "memory cleaner" apps bubble to the top of the download charts on the iOS AppStore, yet I am always puzzled: How can these apps figure out how much memory is used when they are sandboxed and can't access any memory outside of their process?
I'm not an expert in memory allocation on C, so maybe the solution is obvious and I just don't know it but I am curious as to how this works/could work.
Obviously the second question is how do they clean the memory once they have the count, I assume they just allocate a ton of heavy objects (eg. images) and thus force the OS to shut down other processes. Yet maybe there is a smarter way?
Note, I am not talking about Cydia here, these apps are available on the regular AppStore and work on non-cracked devices with the official consent from Apple. As an example, here is the current top seller: http://iputzfrau.professional-apps.at/
The Mach/BSD host_statistics and sysctl functions are available on iOS, and they provide access to system statistics such as the amount of physical RAM, processor speed and, indeed, the amount of free RAM available. To get the latter, you'll want to call host_statistics with HOST_VM_INFO, and look at free_count in the structure it fills out for you. Note that this value isn't necessarily useful for any real purpose. You probably don't need it unless you want to write yet another one of these scammy apps.
Low-level functions in the C/UNIX/Mach/BSD layer are generally available for use in iOS apps, although these APIs typically aren't described in the SDK documentation. Look at the headers in /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/ and refer to the Mac OS man pages, C/UNIX standard documents or the Mac SDKs for more details about them.
These apps, as with the "track any cell phone" apps that have "for entertainment purposes only" buried in line 30,239 of the description, are scams. It's exceedingly frustrating that Apple lets them through the review process.
You're right -- there's no public API that would enable an app like the one you linked to do what it claims to do.
This would be an excellent question to pose to Apple, or at least post in the Apple developer forums. You could also report a bug, probably the most effective way to register a complaint without knocking yourself out.
I am working in iPhone SDK.I have to convert from it to Crossplatform which may be either phonegap or titanium.As a iPhone Native application developer, I have some questions based on cross paltform.please consider the questions for other platforms android,etc also.I have already seen the stackoverflow Link.
1)Is it possible to get equal functionalities of all APIs which are in iPhone SDK through HTML5 and javascript?
2)If Apple releases New Version of iPhone SDK,will New APIs be included ASAP in Crossplatform?
3)If The App crashes in some situation, can I fix immediately through Device Debugging as we do in native Language?
4)The applications developed by Cross platform will be approved by Apple legaly?For example If i want to do live streaming in iphone , The restrictions have mentioned in Apple website.has it been followed by crossplatform?
5)will Application developed by cross platform take more memory?I mention the size of device build for appstore?If we develop the same through objective C,will size be reduced?
***My Conclusion is When we want to develop simple Applications for Multiple devices,crossplatform is suitable.Am I right?***I hope doing through native language(iphonensdk, Android) will avoid lot of Unnecessary things.
No.
If the API can be made available, it depends on how fast the creators of the framework implement it.
In principle, yes, as those frameworks employ a limited amount of OS capabilities to run web-technology (in most cases). This "wrapper" behaves as any native app does. For the content however the rules of the frameworks development language apply. It may be harder compared to native development to track down errors, since they must "pass the shell". Html errors for example may produce the same error for their enclosing webview again and again, despite being different in origin.
Propably.
That's hard to tell. It may depend on the framework. I wouldn't worry about the code as other ressources like imagery are usually the heavier load. But it may be very well the case that those frameworks bring along imagery necessary for their UI elements, since they do not rely on OS elements entirely. Compared to a native app which comes with no extra ressources at all, a crossplatform app with the same functionality might take more memory.
As to your conclusion: You're right. However I'd still encourage anyone to develop native applications whenever possible. Crossplatform frameworks tend to be slower at runtime and, in some cases, produce very ugly apps. I know several examples of apps which have been created with a variety of crossplatforms and I don't like any of them. They just don't feel right. Partly that's due to their UI elements which don't look and feel as you'd expect it on the platform you're on.
The principle behind crossplatform frameworks may appear to be logical, tempting and in some cases, straight economics mandate their use. But, for the time being, I find the results far from being satisfactory and for that reason would never touch a crossplatform framework.
In my experience (with a closed, private, expensive x-platform thing purchased by the employer), it was utterly frustrating, and incredibly difficult. Therefore, it is my preference to maintain multiple native apps.
The UI considerations that can be made/handled by the native app, as well as the functionality and speed gained by doing it natively, IMHO, far outweigh the benefit of having to write it 2 or 3 times.
In an ideal world, you would have a specialist for each platform that can lead the team on the "deep" things, and then everyone can generalize for all of the platforms, increasing their depth through the course of the project.
I am working on iPhone app development currently (primarily native app using Obj-C and some web app using jQTouch). My question is regarding the future of this space;
In say 3 years time, what do you think would be preferred (native or web app) ?
What are the strengths going to be for native app (I know for certain types like Games, people prefer native than browser-based, but will that remain that way forever)
Some people say HTML5 will replace native app development, as it will be "code once, run anywhere" kind of thing (like common for iPhone, Android, BB phones). So do you think HTML5 can completely eliminate native app development.
I know the mobile space is constantly changing with new technologies coming up regularly and hence one cannot say with certainty what the situation will be 3 years forward. But I think there are projections being made by many agencies. So are there any reputed ones which can give a general idea or some sense of what might happen in future.
My main aim is what exactly should be my focus (like what technology/platform/native-web apps), if I want to look at the mobile space for the next 5-10 years.
Please provide as many responses as possible.
My 2c.
The popularity of web based apps will continue to grow. Whether it will pass native apps I don't know. For them to be on par in terms of numbers in 3 years doesn't seem unrealistic.
Native apps have the following benefits:
Better performance (potentially)
Fewer restrictions on accessing device resources
Greater control of execution of application
HTML5 won't completely eliminate the need for native apps (see point 2 above). Even Google who are creating an entirely web based OS (ChromeOS) don't seem to be looking to get rid of Java/Dalvik for Android based dev.
"code once, run anywhere" is very unlikley for anything but the simplest of apps/functionality.
"Code once, compile for each supported platform then test everywhere" is much more realistic.
I'd recommend focusing your education on what makes a great mobile regardless of platform and looking at web based development.
1: Native. It will always be preferred, as it is the most convenient type of app. Personally, I only have one web-app on my phone.
2: The iOS-framework. It is really the largest upside of the native apps. And the fact that they are easily downloadable through the App Store.
Not so long ago iPhone development was quite simple, only a few OS versions and even less devices.
Now however, there are 2 major OS versions and 5 different devices to consider.
As a company about to release several applications testing has been become more and more of an issue.
What are the best ways to test all combinations, do I need to acquire every generation of iPhone and iPod Touch? Are there any gotchas with specific hardware/OS combinations I might need to code around?
I guess my question is, "What's the minimum amount of testing required to cover all the bases?"
In my experience, you won't have much compatibility trouble between iPod/iPhone. There are other gotchas to be aware of:
The devices run at different speeds. iPhone v1 and iPhone 3G run at 412MHz; iPod Touch runs at 532MHz, and the new 3GS runs at 600MHz. This can have a big impact on performance and even functionality if you're getting fancy.
There's a huge performance difference between EDGE/3G/WiFi networks; often the differences are counter-intuitive. EDGE can often have better latency (time to first byte) than 3G, while 3G has 10x better bandwidth. You'll want to test your app under all three conditions.
Are you using Core Location? iPhone v1 and iPod Touch do not have GPS.
Are you using the camera? The iPod Touch does not have a camera.
Is your app compatible with jailbroken phones? A lot of people have done it, and if your app crashes on them, they will blame you, not the Dev Team hackers, and this will be reflected in your App Store ratings. Note especially that background apps can use up memory that you might have thought would be available exclusively for your app. Leave yourself some overhead.
So, what do you need to buy? If you're a serious developer, yes, you should have all 5 devices available. But do you need to test every build on all 5 devices? Does every one of your developers need 5 devices each? No.
One developer can probably test everything that matters with one iPhone 3G and an iPod Touch. Toss in a 3GS and your coverage is probably nearly perfect. (Note that development on 3GS is much nicer just because the CPU is faster, so your apps deploy more quickly.)
At work we have one device per developer, but they're a mix of 3G and iPod devices (and, today, one 3GS).
I don't have much experience with the iPhone itself, but in general this might be a good application of pairwise testing. In practice, you can get 90% coverage with a small fraction of the testing of an exhaustive test pass. Then later if you find certain configurations have gotchas you can add them to your set of configurations and still not need to do an exhaustive pass.
I am not sure if its a best practice.
But I have heard many people using ibetatest for exactly what you are looking for. Lots of enthusiastic beta testers out there.
You shouldn't have any issues on 95% of your code running on different versions, and something like ibetatest should catch the remaining 5%.
Get all the combinations is the short answer.
I started out with just the iPod, but it's 100MHz
faster than the previous iPhone model. My app's
performance sensitive, so I'm gonna have to get
an old iPhone. I can hardly ask my beta testers
(volunteers?) to run the GL performance tool.
I'd suggest a couple things:
you probably will need a range of devices for your own internal testing. As has already been pointed out, there are various differences between each generation of iPod Touch/iPhone
you may want to look into using crowd-sourcing to supplement your internal testing. This potentially allows you to have a bigger audience to test your apps and any cost of using crowd-sourcing is potentially offset by the fact that you can spend less on devices and potentially less on internal testing staff and at the same time, potentially producing a better product. One crowd-sourced test group not mentioned above is uTest.com
I know there are emulators, but is this good enough? If someone is serious about iPhone development, do they absolutely need an iPhone?
Just my personal opinion: if you're serious it means that you're committed to quality of your product. If you're committed to quality there is no way to deliver a product without actually launching it on the target platform :)
As noted in other posts you'll have tough time testing the multi-touch screen and other aspects of the hardware on your emulator.
Don't forget that most types of iPhone apps also work on the iPod Touch, which is a one time cost and no monthly fees. Even network apps work if the iPod Touch is connected to WiFi.
During development of my first iPhone app, I wrote code that worked fine on the iPhone Simulator, but which did not work on the device. So I would say "Yes, you definitely need to test on an actual device."
The simulator is not an emulator. It is not running the actual iPhone OS; it is running a set of Mac OS X libraries that are very similar, but not identical, to iPhone OS. The simulator is great for debugging and saving time during the code-and-test cycle, so you will use it a lot more than the device, but a device is indispensible.
You really do need to touch-and-feel your app on a real device. A UI that works great while pointing and clicking with a mouse might be terrible when used with thumbs and fingers. If there is any text entry, you need to feel how painful it is to type using the onscreen keyboard, to determine whether it makes sense to provide alternative data-entry methods.
There are also significant performance differences between the simulator and actual devices. You need to test with the oldest (slowest) device you want to support to verify it is not too slow, doesn't run out of memory, etc.
As others have suggested, an iPod Touch is also sufficient, so the cost of a device isn't huge. Also, try to find beta testers with a variety of different models.
Necessary: How the app handles in your hands is critical to something like the iPhone. you cannot tell how it will feel to use when plastered straight in front of you in the emulator on a big screen.
If you cannot hold it you won't be getting the true user experience.
If you need to learn Obj-C, go with the emulator for a while until you learn the ropes and save the expense for later. But yes, eventually you will need an iPhone for final testing. How long you can wait will depend on the features that your app uses, If all you are doing is button presses, you can wait a long time. If you are dragging, using location services, etc., you'll need a device earlier in the development cycle.
Are you trying to convince yourself or your boss? ;-)
I'd say you need one. Emulation of such a new device can only go wrong. Plus don't forget the tactile aspects.
The iPod touch is a reasonable substitute provided you are not using:
GPS, BlueTouch or Camera - the iPod touch doesn't have these
Cellular network - although the iPod touch has WiFi, the latency of a cellular network is way way higher than that of a wifi network. If you are doing anything like designing a custom protocol for your application, you will want to check real-world performance - and if you do this too late in the development cycle, you will be in for an unpleasant surprise.
Whether you develop on the iPod touch or on the iPhone, you absolutely must have a device. This is not optional! The simulator is good, but it is not perfect, and there is no substitute for having a device which correctly indicates performance, screen resolution, brightness, form factor and all the other factors that you will need to consider in your application.
If you buy an iPod touch, you will probably end up getting an iPhone too. I'd just go straight for the iPhone. That way you can use it as your main phone, and get a real feel for how the platform behaves and what an application needs to do to make it great.
Kind-of "yes".
Just download iPhone SDK (it's easy and free) and check out the emulator that is in there. You'll see whether that suits your needs or not. The emulator is not indicative of real hardware performance, there's no touch input, some quirks might be different, some things can not work, etc.
The iPhone Simulator makes it easy to test your applications using the power and convenience of your desktop or laptop computer. Although, your development computer may not simulate complicated touch events, such as multifinger touches, the Simulator lets you perform pinches. To perform a pinch, hold Option while tapping on the Simulator screen.
I'd say it depends on the kind of application you are developing. For a successful iPhone app, one which is properly integrated on the system, you are going to need to be able to test your tactile interface. That's hardly accomplished with the Emulator.
So, my answer is Yes, you do need an iPhone to develop iPhone apps. Fortunately, if you cannot afford one, an iPod Touch (200 bucks) is a very competent replacement. The underlying hardware is pretty much the same.
Necessary. If you plan to develop a successful product it needs to be one the end users (not just the developers) find easy to use.
The best way to do that would be to load your app on an iPhone then take it to various people and ask them to use it while you watch them to see if they experience any issues.
Users can get mighty creative in trying to do things a developer never intended - just ask any support tech.
Unless you're app is going to sell for less then $500 total it's a relatively small investment to build a quality app.
If you are serious about development, an iPhone (or iPod touch) is a must. However, the official SDK comes with a very complete "iPhone simulator". This will allow you getting a feel for Objective C and the entire development workflow. The SDK requires Leopard.
You don't need a Mac for this. You can use OSX86 on your PC, either installed on and booted from disk or through VmWare.
It works. In fact, you can even synch the iPhone through Leopard running in vmWare.
Now, testing on a real iPhone is a necessity because of performance, memory usage etc. Also you need it for the entire authentification procedure, getting the keys etc. (if you want to sell your stuff on the Appstore), testing this really requires an iPhone.
If you buy an iPod touch, you will
probably end up getting an iPhone too.
I'd just go straight for the iPhone.
That way you can use it as your main
phone, and get a real feel for how the
platform behaves and what an
application needs to do to make it
great.
I absolutely agree with this.
If you are seriously developing an iPhone application - for fun or for profit - you will have to run it on a real iPhone to test out compatibility and usability at some point. Since you going to have to get one at some point, you may as well get one now. Don't go for half measures. An iPod Touch may be [significantly] cheaper to start with, but will be money wasted when you go and get your iPhone. (Of course, if you are planning an app that runs on the iPhone as well as the iPod Touch, then you MUST test it on both. You cannot assume that if it is good on one it must be good on the other).
Also, by having an iPhone from day one, you can familiarize yourself with its user interface, its norms and the common metaphors the apps use. That will heavily feed into your own application design process, and make sure that your app looks, feels, and works like a first class iPhone citizen.
From experience developing on other mobile platforms, once you get to a certain point, it really is best to have a physical device to test on. If this is something that you would also be using yourself, if it much easier to get some real world type of testing by using the application out and about.
I also think it helps one to understand the platform better by having the device or devices you are targeting with your app,
if you are going to develop native apps for the iphone, I would say get an iphone or ipod touch to target. emulators are good, but eventually you will need to target the real thing. if you are developing web specific content there are lots of things you can do without it (there are some great dev videos free from apples dev site which will only cost you a sign up) but eventually I would think you would still want to test with the real deal
Get a cheap used iPod touch, develop, get money, buy an iPhone 5.
I'm a nokia dev now, I'm thinking of going to iPhone, Actually I have the Mac to work, just the device itself ;)
I've tried iPhoney and compared to my iPhone (Mark 1) it's not the same, it's close - but not close enough to rely on if the interface is of importance to you.
You absolutely need the real device. The performance difference between the simulator and the actual iPhone/iPod Touch hardware is huge. Code that will run nice and fast in the simulator can easily turn out to be too slow to be usable on the real thing. Also the API provided by the simulator is not 100% identical to the real thing, so code that works fine in the sim, may not work on the device. The only way to know for sure is to test often on the actual device.
As others have mentioned, the iPod touch works well as a development device. So if you don't need any of the features of the iPhone, it's a good, cheaper, alternative.