So I am developing an app for a company and am under quite a time pressure now. It is yet available for 3.5 and 4 inch. But since Apple has just released the new screenSizes, do they possibly reject the binary I upload for review if it is not made for the new sizes? Because that was the case for when 4 inch was new, I remember.
Did anybody release an app since the release of iPhone 6 and 6+ yet?
Thanks in advance
The app must work on iPhone 6 and 6+.
You should test it (e.g. in the simulator). If the app doesn't crash, even though things appear somewhat disproportioned (too big), compared to other iDevices, then you have a high probability there will be no problem, since the scale is the same as on 4 inch devices.
You need to upload screenshots for iPhone 6 and 6+, too.
Related
React Native APK size for a hello world example is around 20M (in recent versions) because of support different hardware architectures (ARMv7, ARMv8, X86, etc) while Flutter APK size for same application is around 7M.
What's the reason for the difference in size? Do Flutter support all hardware architecture?
So Junius answer is correct but I don't believe covers the reason why. So Flutter compiles to 100% native code, where RN uses a combination of native code and JavaScript communicating across a bridge.
That is why Flutter does not need to add the JavaScript core thus, the size is smaller. But anyway, as your app grows, the JS part will always be around the same size.
Visit to below mentioned url's and may be they could help you out regarding what you are looking for.
https://nevercode.io/blog/flutter-vs-react-native-a-developers-perspective/
https://android.jlelse.eu/comparing-apk-sizes-a0eb37bb36f
if not it will still give more insights to others on how Flutter is different than others, and whether one should choose flutter over any other hybrid app development technology or not.
RN use open source JavaScriptCore, which is the default engine for Safari. RN iOS and Android apps don't have the same size. For iOS RN uses the JavaScriptCore provided by the iOS platform, and for Android RN bundles JavaScriptCore with the app, which increases the size of the app. The reason why Flutter and RN Hello World differ in size is because of JavaScriptCore.
The day before yesterday I published an Flutter application in which there are also images. However, the application has libraries that are not small like Firebase and I managed to make it become 2.3 Mb. Instead, I have another Flutter app that I published and weighs 8.5 Mb, do you want to know the only difference? The Api Min starts from 21, while the one that weighs 8.5 from 16. This is a big advantage because 2.3 are very few. Only in debug mode the size is very large, so don't worry, because when you compress the flutter application in appBundle for example to the Play Store, the size of him smallest very more.
I am trying to transfer 2 megabytes worth of data using the new multi-peer connectivity framework in iOS 7. I am finding that sending and receiving 2 megabytes of data takes at least 5 minutes. This seems very odd. This is between an iPhone 5S and an iPad 3 in the same room. Problem happens regardless of whether WiFi or Bluetooth are enabled or disabled and whether reliable is on/off.
// self.session is an open MCSession, packet is the 2 MB of data, reliable is YES or NO, both are slow
[self.session sendData:packet toPeers:peers withMode:MCSessionSendDataReliable error:&error];
I'm pretty sure this is because the iPad 3 is the bottleneck. Transfer from iPhone 5S to iPad Simulator on my MacBook Air for a 10 MB file was about 1 second. My theory is that only AirDrop enabled devices will get fast transfer speeds - http://en.wikipedia.org/wiki/AirDrop.
EDIT My assumption was wrong, transfer between two iPhone 5s is just as slow :(
EDIT Switched to streams API and it's much better
EDIT Tweaking wifi channel settings on my router has helped performance, but it still seems slower than it should be. 10 MB transfer now takes 30-60 seconds instead of 5 minutes.
EDIT I solved the problem by converting the images to JPEG2000 which is vastly smaller than PNG, even though the transfer is only like 100K a second it now finishes in a reasonable 5-10 seconds. See this stackoverflow answer: How do I convert UIImage to J2K (JPEG2000) in iOS?
EDIT Disabling encryption has also helped with transfer speed
Hoping someone can confirm or refute the fact that it appears that achievements don't show when they are achieved. When run on an iOS 6 device the achievement shows up but when run on the iOS 7 it doesn't show up.
Using showsCompletionBanner set to YES. https://developer.apple.com/library/ios/documentation/GameKit/Reference/GKAchievement_Ref/Reference/Reference.html#//apple_ref/occ/instp/GKAchievement/showsCompletionBanner
Atm I assume it's a bug in iOS7 and it will be fixed (who knows) so I'm not touching any code.
So with this question having no real answer for some time.
In the end, completion banners really do show in live apps, I guess, most of the time... eventually. While developing they don't seem to appear a lot of the times though but this should not affect the live version. I guess for various reasons a lot of these network related features don't always work 100% on sandbox servers, be it Game Center, or IAP related. This is my experience working a few years on iOS apps (above 60) anyway. I haven't done a lot of iCloud enabled apps so can't answer for that.
Of course, I haven't been doing GC achievements lately (like in the last month) so it is possible that responsiveness is better now for sandbox also.
I can only partially confirm that:
achievements obtained in iOS 7 do show up in Game Center (on the same iOS 7 device);
achievements obtained in iOS 6 do show up in Game Center (on the same iOS 6 device);
however, achievements obtained on an iOS 6 device DON'T show up in Game Center on an iOS 7 device (and vice versa), even though they're logged in with the same user.
It's like iOS 6 and iOS 7 use different repositories and are not synchronized.
I'm a newbie developer who worked on Movist media player over the last months.
The project seems to be dead so I started to look at the code and try to understand how it behaves.
I have been able to add hardware decoding (with VDADecoder), fix all deprecated functions, plus other minor things and everything seems to work nicely on Snow Leopard.
When testing the app on OSX Lion, instead, I encounter a very annoying issue and I'm short of idea because I tried quite everything..
The video playback freezes for about 0.1 - 0.2 seconds always at the same instant during the playback. It seems to freeze just when the decoder reaches the end of file and when the remaining (already) decoded frames get displayed.
The issue appears with both hardware and software decoding and it's not related to the part of code that I have added.
Obviously, the same movie file plays smoothly on Snow Leopard (with both software and hardware decoding) and on Leopard (with software decoding) (hardware decoding isn't supported).
I tried to use Instruments to debug this issue but I don't know how to catch that instant. Sometimes Instruments records a lot of "sys enter trap" around that instant..is this a hint?
I tried to rebuild the project with Xcode 4 and SDK 10.7 and to fix all the warnings but the issue still persists.
Is there a way to debug this issue?
I don't know how to discover the bug...if there is any..
I hope you can help me.
Regards
Andrea
Just to let everyone know, I found what was causing the issue.
It was given by the Restorable feature of the movie window which was causing that periodical stuttering.
To program for the iPhone, you need an iPhone. That's because you have to compile the final version of the app on the iPhone hardware.
Do you also need an iPad when you program for the iPad? Or will an iPhone also do the job?
You do not need to have an iPhone to be able to compile your program for the device, and you do not need to have an iPad to compile your program for that device either. It's good to be able to test it on an actual device before you submit it, but it is not necessary. All compilation happens on the computer, not on the iPhone or iPad.
You should have one. Those of us who released iPad apps on iPad release day can certainly tell you that there are differences between the Simulator and the device. I had two minor but ugly errors which went out with our first release of Reiner Knizia's Money for the iPad, one of which had to do with different case comparison on the two devices. I would have never seen them if I didn't have a device to check.
I would imagine that for testing alone you would need an iPad. Although I've never developed on either one, basic quality control says that you really should test any app on the actual hardware it is intended to run on.
I'd say Yes, you need an iPad. Reasons, precise and real memory warnings, device wifi's real speed latency, 3g. And here's the tricky one: Some libs/features just don't work on the simulator but they work on the device and viceversa.
But I mean, you can always be googlish and search for these later cases I mention, and just be sure that you are doing things right. Otherwise, get yourself an iPad, you don't lose anything.
-edit: I didn't read the question correctly... the short answer: You don't need an iPad to compile the final .app file, but take my advice.
YES. (Unless you have no respect for your users and don't care about the quality of your app)
No. You don't even have to get a developer license from Apple. You can just download XCode and the official iOS4 SDK and develop the application in the simulator.
However, there's small caveat - the simulator does not always behave like the real device. So at some point you want to have a device to test your app on.
It would certainly help to have one, but not necessary at first. Get some experience programming for your iPhone, and once you feel ready, start working on something for the iPad. The simulator works great for most tasks. However, I wouldn't release any finished product to the app store unless it had been thoroughly tested on hardware.
There are cases where it is necessary to have hardware. For example, I was doing some testing involving dragging your finger across the screen. I needed to step through the debugger while doing this. Using the simulator was impossible, since I couldn't lift my mouse pointer from the iPad screen and interact with the debugger at the same time. Having hardware allowed me to interact with the device, while working in XCode at the same time.
Not having the target device for your software is a recipe for poor user experience. Touch interfaces cannot be accurately duplicated with a mouse. There are also very specific problems with relying on the iPad simulator:
1) The actual iPad has a slower processor than the desktop simulator. Stuff that looks fast in your simulator can be slow on an actual iPad
2) The iPad simulator is not fully correct, especially in simulating web browser experience. Real iPads have weird painting issues, CSS sanity differences, caching oddnesses, and then just more crashes than the simulator.
3) Orientation changes need to be performed on a real iPad! The simulator can just misleading. Ditto for network fetch latencies, which can affect the user experience significantly especially on a 3G link. If you don't have a real iPad you'll never notice that you need load masks, "waiting for content" watermarks etc.