Care to elaborate? Like, throw a few names this way?
Screenshot Plus widget doesn't seem to get the job done.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Officially Invites Developers to Submit iPad Applications to App Store
- Thread starter MacRumors
- Start date
- Sort by reaction score
Care to elaborate? Like, throw a few names this way?
Screenshot Plus widget doesn't seem to get the job done.
Interesting point of view. Strange and confusing, but interesting. All I've read is a lot of excitement about a cool, useful and potentially game-changing new device, some wildly negative speculation by the usual crowd of obsessed Apple haters and a few people pointing out blatantly obvious things like the fact that testing applications in a simulator isn't the same as testing on actual hardware.
Given that we're talking about a 100% solid state device running a popular and stable operating system built by a company with an outstanding track record of delivering well-executed new products, I'm not sure where your FUD is coming from.
Memory leaks are logical bugs, on the Obj-C level. If you leak on the device, you will leak on the simulator as well AFAIK. Correct me if I'm missing something...
I would say being unable to test the actual user experience (multitouch on your lap vs. Option-drag mouse on the simulator) is the biggest limitation.
That and CPU speed/available RAM.
If it crashes because you cause an exception, it should crash in the simulator as well. If your app crashes because a leak used up all memory on the device,
it may not crash on the simulator but you will nonetheless be able to find the leak...
So much for leaks, feel like going to the toilet...
As a developer, this is disappointing news. 8 days notice to submit your app when betas are being released less than 2 weeks apart? Meh.
I was working towards hitting the launch but I've slipped due to a few different reasons, one of which was limitations of the SDK. There has been no news until today other than something along the lines of "until your app is tested on a real device you won't be able to submit your app". Suddenly that changes 2 weeks before release.
I hope apple knows what they are doing, I'm expecting mostly trivial software and ports from the current iPhone apps on the 3rd. I know of a number of interesting projects in development that will shine on the iPad, but there's not been much time to take advantage of since the announcement at this point and none will be ready for that.
I'm a bit torn myself... do I put my big project on hold for a week and release a couple of shovelware apps to make some money and then do my real project a bit later? I hate being in that position. I don't want the iPad to turn into goldrush 2.0 with the users reluctant to buy software because they won't like what they purchase.
It's cool for users that they are doing this no doubt, I'm sure there will be some quality releases, especially from the people that are already hands-on with the devices. As an independent developer I'm very disappointed. They totally could have made this happen with more disclosure to the developers on the timeline.
I was working towards hitting the launch but I've slipped due to a few different reasons, one of which was limitations of the SDK. There has been no news until today other than something along the lines of "until your app is tested on a real device you won't be able to submit your app". Suddenly that changes 2 weeks before release.
I hope apple knows what they are doing, I'm expecting mostly trivial software and ports from the current iPhone apps on the 3rd. I know of a number of interesting projects in development that will shine on the iPad, but there's not been much time to take advantage of since the announcement at this point and none will be ready for that.
I'm a bit torn myself... do I put my big project on hold for a week and release a couple of shovelware apps to make some money and then do my real project a bit later? I hate being in that position. I don't want the iPad to turn into goldrush 2.0 with the users reluctant to buy software because they won't like what they purchase.
It's cool for users that they are doing this no doubt, I'm sure there will be some quality releases, especially from the people that are already hands-on with the devices. As an independent developer I'm very disappointed. They totally could have made this happen with more disclosure to the developers on the timeline.
I think you've overinvested yourself in the Apple product launch theater.
But more directly to your point, developers have the tools in the SDK to program with. If there is some last minute addition to the iPad, it would have nothing to do with app submissions based on the current SDK and due date, so having access to the hardware to test your app on March 27 before submitting it would accomplish nothing.
No, there is the understanding that the simulator exposes everything about the iPad that the developer can control. They don't have access to the hardware for development purposes any more than PHP developers have access to the hardware. You're dealing with a high-level programming environment substantially more restricted than XCode on a Mac.
The level of programming that would require testing against the silicon is not open to App developers at all.
This is an Apple framework. Any such issues would have to be addressed by Apple.
Almost entirely irrelevant, but even granting the existence of such "issues", easily shown in the simulator or design stage mockups.
App store developers are not pilots, and high-level programming interfaces are not commercial airliners. You use software every day that wasn't tested against your hardware configuration before release.
For software that doesn't ever interact with hardware directly, it absolutely is. Testing is done against multiple software environments in virtual machines, which is essentially what the SDK simulators are. If the application doesn't access the hardware except through public frameworks and APIs, there's nothing within the developer's control to test in hardware.
agree.
i don't even understand why macrumors has the stupid voting system anyways - it's a complete waste - look at pretty much any article and there is always a random pos/neg percentage of votes. people were recently voting positive about the death of an apple board member in large numbers. there's a reason why none of the other forums use a "voting" system...
to each his own - yes?
i would prefer to own an iPad as soon as possible and then sell the first gen when i "upgrade" to the next generation (whenever that will be) because i will have already enjoyed months or maybe an entire year of use before the next generation release. but for those on a tight budget and without immediate uses for an iPad i might wait.
absolutely true - this is quite the opportunity for those to create one of the early apps and get downloaded by hundreds of thousands of early adopters for this new device - before the iPad store becomes saturated like the iPhone app store...
Universal iApps?
If you can post different screen shots for (i) iPhone/iPod touch apps, and (ii) iPad apps... this tends to suggest that the one app could work quite differently on the different sized devices.
Why would you bother having two different sets of screen shots if the iPad version was simply a scaled-up version of the iPhone app.
I really like this... as it means that I will only need to purchase (and manage) one version of each app... instead of two.
The only downside, that I can see, is that presumably those extra iPad features (that are redundant or non-operational on the iPhone) will take up disk space on the iPhone... but this is price that I'm quite happy to pay.
If you can post different screen shots for (i) iPhone/iPod touch apps, and (ii) iPad apps... this tends to suggest that the one app could work quite differently on the different sized devices.
Why would you bother having two different sets of screen shots if the iPad version was simply a scaled-up version of the iPhone app.
I really like this... as it means that I will only need to purchase (and manage) one version of each app... instead of two.
The only downside, that I can see, is that presumably those extra iPad features (that are redundant or non-operational on the iPhone) will take up disk space on the iPhone... but this is price that I'm quite happy to pay.
I wouldn't agree with my reservations being characterized as FUD. It's just that I am withholding judgment until the iPad is more mature.
There have been many tablets and none have been successful. There is also little evidence that the public wants this type of device. Why will Apple get this right? At least with the iPhone there had already been successful smart phones on the market.
I have nothing against the iPad (unless it is taking away resources from the Mac - and I have no evidence of that). Just as being an early adopter can be exciting and is legitimate, waiting until a device and platform matures before purchasing is also legitimate. No FUD coming from here.
Yes actually this entire post is pure FUD.
You have no basis for any of this, because your phony fears don't apply. Nothing about this device is unknown. We know what it is, we know how to use it, we know what it does. There is no big mystery "Gotcha!" that will arise once it goes on sale. It works. Trust me.
This ridiculous question of "Why Will Apple get it right" was a question for before Jan 27th. Long since answered. Their product offering is clear and public. The who, the what, the why, the how is all answered. All that remains is for it to be used and enjoyed.
I could see someone being skeptical of the touch interface and software, if, you know, there wasn't already an iPhone and iPod touch for 3 years!!
The iPad simulator is very different:
- You can only test 'pinch' multi-touch gestures
- You have pretty much unlimited memory, compared to the much smaller amount on the device
- The iPhone OS is case sensitive, the simulator is not
- Depending one the development machince, performance can be a huge difference
- The mouse is more acurate than a finger, so the UI might not be as useable as it seems
And so on...
"Trust me." Yeah sure. Who are you? Take it easy. Have you held the iPad in your hands and used it? The answer is clearly NO. So your suppositions are just as phony as everybody's, including me, who have not actually used an iPad.
There are still a lot of unknowns and there will be until it is released.
Take a deep breath. It's OK for others to have differing opinions.
You obviously know nothing of which you speak. PHP is a scripted language, interpreted in realtime - you are correct, the programmer has little to test on hardware in that situation. But we are programming in pure C++/Objective C/Assembly, our code natively runs directly on the hardware, controlling it. We are not allowed to directly touch hardware features like the screen or camera, true, we have to access those through Apple's libraries, but that doesn't mean much at all - programming a 3D game in OpenGL on the iPhone is just like programming a 3D game in OpenGL in Windows or on a Mac (except that it's actually OpenGL ES, which is optimized for embedded devices).
Here's an example of why testing on actual hardware is important, and many apps just can't be released without it. Imagine you were programming a simple air-hocky game - just a single puck flying back and forth, each player hitting it with a paddle on their side of the board, controlled by their finger. First of all, that is *impossible* to test on the simulator alone - on the iPhone simulator, there is no way to simulate more than one touch, except in a specific case testing pinches (and even if you could, that would be playing it with two mice, quite the different experience from your fingers on the screen). So you'll never know if your game is actually fun to play for two players, or needs control sensitivity tweaked (like how fast the player's paddles are allowed to move), puck speed/angles adjusted, things like that.
And more important, the speed of the puck flying back and forth - without actual hardware, it's impossible to determine how fast to program the puck to move. The hardware speed is completely different from the simulator, without hardware there's no way to tell if you've programmed your puck to go too fast to even be followed by the player's eyes, or so slow that the game is incredibly boring. And maybe you're using this super-awesome puck and paddles each using 5000 polygons, on a 10,000 polygon table - can the iPad render those at full framerate? Maybe you need to optimize things a bit? Without hardware to test on, who knows? The Simulator does 3D at the speed that your Mac can render the 3D, emulating OpenGL ES.
Or, if you've got a snazzy animation that plays when a goal is scored, that requires precise timing of a sound effect, you need to know exactly how long that effect will be on the screen for it to be perfect. Timing of anything is impossible on the simulator, you need hardware for that.
It's pretty stupid that Apple didn't do a developer program for getting early iPads (even if they were limited.. consider the first Intel developer Macs). You can do some stuff in the iPad Simulator but how about.. oh.. multitouch? Or.. oh.. accelerometers? The closest to multitouch you can get in the simulator is playing with the pinch gesture, so that makes many action and driving games totally unplayable by developers before submitting them to the store. You either end up with a sloppy untested game in the store or Apple refuses to put it on anyway..
Again, the gestures are Apple frameworks.
These are concerns for complex, large applications, not ones that can be slapped together in 2-3 weeks for launch. Most of the app store will be available from day one with no tweaking required whatsoever--titles developed before anyone even knew of the iPad who had neither the software nor the hardware to test against. You're vastly overcomplicating the development of most titles on this platform.
There are developer guidelines for this.
My point exactly. It's exactly like that. OpenGL removes you from the hardware--that's the whole point of its existence, to act as an efficient abstraction layer for development on multiple hardware configurations. Programming a complex 3D game is a different kind of project entirely from the sort of development that can occur in a 2-3 week window. I'm not talking about that. You're talking about project development that takes months and actually has significant performance and resource issues to deal with, and for that absolutely a simulator is not enough.
But you're losing sight of the fact that application software developed in two weeks isn't going to run into those sort of problems. Projects with development times of months, with edge case 3D issues actually requiring hardware testing aren't the submissions that will happen by the 27th. Even if they had access to the physical hardware, their software itself would not be ready in time for launch.
On the other end of the spectrum, the majority of app store apps will run directly on the iPad without any developer intervention at all.
It's not 1985 anymore. A simple game like you describe is not dependent on hardware speeds for movement timing. The turbo button on the case is long obsolete.
Yeah, no. Timing of movement on the first generation iPhone, the intermediate models of iPhones and iPod touches, and the iPad is all managed. Games don't speed up or slow down based on whether its on a 412MHz iPhone, a 625MHz iPod touch, or a 1GHz iPad.
C# programmer here, this will open lots of opportunities for indie developers. Lots of creativity will be seen in all these aps, some Touch remakes perhaps.
Stop it! You are using logic and clear insightful thought, there is no room for that in this here forum. We want drama and negativity!!!!
Um, so? What does that have to do with testing to see how a gesture that you programmed works for your app, if it's the perfect thing for it or if it just makes things harder/more complicated to use?matticus008 said:
Again, what does this have to do with anything? A huge number of those apps will be crap on the iPad because they didn't get any tweaking done. Quite a number of high quality games, for example, are dependent on a virtual d-pad at the bottom of the screen. A screen that is now huge and heavy, nobody will be able to hold the device and use a d-pad at the bottom of the screen. So, let's say a developer uses their two months of iPad development to take one of those games, upres the textures and game window to the iPad resolution, and alter the controls to ones that would be better suited to a large device like that. How do you expect that company to test to see if their controls really are usable on the device and easy to control? It's hard enough to get a virtual d-pad to feel good when you've got a device to test on during developent.matticus008 said:
Finally you are starting to understand! In terms of games, this is the case with almost all iPhone games. Even a simple card game can take enough time loading a card to cause a pause, depending on how fast the system file system is. Especially on iPad where you will be loading much larger, more detailed cards. Don't you think it would be good for developers to find out if their game is pausing every time a piece of art is loaded? If they need to optimize their graphics engine more, or compress the card art, or preload it (and find a time to preload it where the pause wouldn't be noticable)? And that's just one little thing that could affect enjoyability of a game.matticus008 said:
You are assuming quite a lot. Why would every iPad app being developed by every iPad developer in the world be only 2-3 weeks of development? Especially when the iPad SDK was released January 27, almost two months ago? You think all developers would have been just sitting on the SDK, not doing anything on it until Apple suddenly allowed them to submit their apps?matticus008 said:
Not to mention all the iPhone games were in development before that. Let's imagine Grand Theft Auto or Assassin's Creed 2 were being ported to the iPad. A couple months is plenty of time to do that, because the games were already done and shipped. They would want to up-res their textures, add more polygons to the models so they don't look as bad when seen on the big screen, and of course completely redo their controls. They would definitely need to test on hardware to get everything running perfectly exactly as they desired. And smaller games would have the same issues.
Concrete example?
And again, these titles wouldn't be ready by launch time either way.
I don't. None of those companies have finished, polished, products ready to go but for usability and performance testing. It will be some time before complex applications are ready in any significant numbers.
You're implying a disparity where none exists. Except for large game developers who have an internal relationship as launch partners, any gaming platform doesn't pick up speed until after the hardware release. Intel and nVidia don't ship prerelease hardware to small game houses, why should Apple?
You continue to talk about a completely different scope of development than what can be achieved here.
Nobody can move on to tackle finishing issues like these until the SDK is frozen. Whatever development that may have taken place had to wait until at least that point.
You can test a large set of one-handed iPad multitouch gestures. There are at least 2 sets of tools (web and App store) that will transmit the multitouch gestures from an actual device (iPod Touch, etc.) into an app running on the iPad Simulator. (Similar to a VNC app).
Same with accelerometer testing. Mount an iPod Touch to a chunk of cardboard the same size as an iPad, and test away by sending events to the iPad Simulator. Or maybe velcro a device onto your MacBook, and move the whole MacBook around.
You can use Instruments to measure your memory usage, on both the Simulator and an iPod Touch.
You can test performance of compute intensive stuff on an iPod Touch. If it runs there, it will likely have even more headroom running it on the 1GHz iPad CPU.
You can test various portions of your UI on both the Simulator and an iPod Touch to make sure your UI touch targets are an appropriate size. The lower DPI on the iPad will make them even easier to use.
& etc.
Do you want to be creative and succeed? Or just make excuses.
Because that's the way it works today when you download apps... you are not double-charged for installing apps on extra devices (e.g. 2 iPhones, 1 iPhone + 1 iPod Touch, etc.).
As far as the iPad version, if the app is a "Universal" app, it should follow the same rules... one download and you can install on any devices synced with your Apple ID. If it is separately released as an iPad version of a pre-existing app (i.e. there are now two separate entities on the App Store), then they should be treated independently and, thus, be billed independently.
Just my $0.02 based on the status quo.