I have developed and updated a medical application for cardiac ultrasound since 2011. One feature of the app is a user-generated document library for documents, images, and movies, all displayed using QuickLook.framework. QuickLook has functioned well until now with iOS 10. At this point .csv files (generated by the app to store calculated data) display as simple text (including the commas) instead of as a spreadsheet. I have not found any Apple documentation to explain this change in behavior. The log in Xcode shows no error messages when displaying a .csv file.
I am using the iOS Simulator at this point to test my app with iOS 10. However, I have verified that the El Capitan (10.11.5) version of QuickLook opens a .csv file in the simulator library on the desktop without a problem, with the expected spreadsheet format. Therefore, I do not suspect any problem with the .csv files that my app is producing.
I suspect this problem with .csv display is a bug in iOS 10, but with no resolution after 3 beta releases, I am concerned that the problem persists. Any help would be much-appreciated. My hope is that there will not be a need to adopt a new document display method, since QuickLook has worked so well for several years now.
Of note, my app does not use any Swift code.
iOS 10 is still in beta and will be in beta until at least the second half of September.
One of the main advices there is while testing beta software is to test it on the real device with something like iOS 10 Public Beta build installed.
If you are 100% positive that this is a consistent, well repeatable bug on Apple's side (not on your own or any other 3rd-party library you might use) consider filing a radar.
Concerning your specific problem, as far to my knowledge, Apple didn't make any significant changes to the QuickLook functionality in iOS 10, but once again, you can prove me wrong, by carefully browsing through all the latest changes in the official iOS 10 changelog.
Related
Running iOS 14.x or lower the UICloudSharingController shows Add People as the last line of the 1st section of the People sheet.
As of iOS 15.x including the new 15.2 beta the row containing Add People is not present.
Anyone know of a work around until Apple fixes this? Apple 1st party Apps like notes do not appear to be affected by this issue, but all my Apps that share using the UICloudSharingController exhibit this issue even those not recompiled under xcode 13.x
I realize this is a stretch and I can't give much info to help but I am reaching for anything. My App has been under continuous development for 3 years and never seen anything like this. I recently submitted a small point release to Apple for Release, and twice now it has been rejected for Crashing on Launch on ALL their devices?
The Crash reports point to some code in static library but the key lines are not getting symbolicated. Tried Atos no luck.
The key point is that I have 7 devices I have tested the app on in every mode I can think of, in particular no connection to anything: Wifi-OFF, AirplaneMode-ON, Location services-OFF. I can NEVER simulate what they claim to be seeing, which is App crashes on launch every time?!
I found one report in the AAPL Dev Forums that sounded similar, but he never got any explanation as to what was up. After he submitted an app with loads of logging in it out of desperation and asked them to send the logs. They got that version and... approved it in hours.
Anyone have ANY ideas. I NEED to get this release out.
NOTE: Resolved
This turned out to NOT be a weak link issue. We only saw the crash when running the App using Ad Hoc distribution of the Archive version as Brad suggested... so that was helpful.
However the resolution turned out to be some compiler flags which I listed here:
https://stackoverflow.com/a/10302012/754494
I'll repost and expand upon my comment from above so that this question can have an accepted answer.
I recently came across a case similar to this when building my GPUImage framework. It appears that the build process is slightly different when archiving than when building and directly installing an application on the device via Xcode.
This can be exposed by building and archiving the application, then choosing to distribute it for ad hoc or enterprise distribution. Take the .ipa and place it in iTunes and manually load it on one of your test devices that way. The behavior of an application prepared in this manner may differ from one built and installed through Xcode, and should be closer to how a build submitted for review will act.
In my case, the problem was due to a lack of proper weak linking. On SDKs newer than iOS 4.3, you should no longer need to weak link whole frameworks if you wish to conditionally use classes and functions that are present in newer SDKs but missing in older ones. If you target 4.0 and higher, the linker should now perform class- and function-level weak linking.
However, this was failing for people using my static library, which does runtime checks for the presence of the new texture cache functions in iOS 5.0, but it only failed in these archived builds. I never saw it in all my testing against 4.x devices, because that was done by installing via Xcode. In the end, I needed to have users explicitly weak link the entire Core Video framework in order to get applications using this framework to run properly when archived and installed via iTunes.
Note that this wasn't due to the Release vs. Debug build configurations, because I tried switching between these in my build schemes when deploying to the device through Xcode and it made no difference there. Something else is different in the way that archived applications are built and linked.
BACKGROUND
We have an iPhone app that uses sqlite for a large database. We use FTS3, full text search, so we have to "roll our own" sqlite instead of using the library included in the iOS SDK. We use the amalgamated sqlite.c file, and we use FMDB as an Obj-C wrapper.
THE PROBLEM
My project compiles, but it crashes on an exception that I've installed to detect if the database is malfunctioning (more on that in a bit). My partner, however, is merrily coding away, with no problems - on the EXACT SAME commit revision as me. That's what's weird.
Specifically, the app does the following on first load:
Copy the database into the user's document directory so that it is writeable. (working OK)
Open the database using FMDB's databaseWithPath: followed by open.
Calling goodConnection on FMDB at this point returns YES - the database is indeed open and working.
Calling SELECT * FROM sqlite_master WHERE type = 'table' returns no records. (there should be many tables)
WHAT I'VE TRIED
Now, if you ask sqlite to "open" a database that doesn't exist -- it'll just create one. That's what this behavior looks like. So, I opened up a Terminal window, navigated to my app's Documents directory on the simulator, and typed:
Makbook:Documents makdad$ sqlite3 myDB.db
Which runs sqlite3, and, of course, everything looks fine. All my data is there.
I stepped through line-by-line of FMDB's open method to make sure I was opening the right database. It looks like I certainly am.
First thing I tried was downgrading to Xcode 3.2.6. Same problem, so I think I've ruled out an Xcode 3/4 difference in compiling (although I suspected that at first).
Does anyone have any debugging-fu to try, or any knowledge as to what my problem could be?
Had the same issue with our custom compiled SQLite3. I found a solution to this problem on this blog http://regularrateandrhythm.com/regular-rate-rhythm-blog/sqlite3-fts-in-IOS4.html
The problem is with the iOS 4.3 SDK Simulator. I had neglected to test the iOS device itself, and it works.
To support older iOS versions, we use the -weak_library /usr/lib/libSystem.B.dylib linker flag. Removing that flag on iOS Simulator 4.3 stops ALL the weird behavior relating to sqlite3.
The reason my partners weren't having the problem is that they are running Xcode 3.2.5, which is 4.2. Even when I downgraded to Xcode 3, I still had 4 installed - so 3 was using the 4.3 SDK as well.
I am going to open a new question about the new issue, as this question is so far off the actual issue :)
I wrote an iPhone app. Then, I changed the interface a fair bit, added higher res images, and made an iPad version of it. In a perfect world, I would like for anyone who buys the iPad version to get the iPhone version for free (though not conversely). Since Apple doesn't seem to have a way to do that (right??), my next favorite solution is to make the iPad version include the iPhone version somehow.
I know that I could just convert the iPad version to "universal", but since the face of the app is so different, that seems like a real pain. I have many view controllers and they are almost completely different between the two versions. Some of the methods are the same, but only about 30%. Is there an easy solution along the lines of this:
Check if device is iPhone or iPad
If iPhone, then use one group of files
If iPad, then use a different group of files
Thanks in advance!
Try creating a new project in Xcode and choose to make it a universal app. In the default way Xcode lays it out, there is a distinct divide between the iPad and iPhone versions. You can make the two versions of the app as similar or different as you want.
In addition, you can check which device you are running on at runtime by using UI_USER_INTERFACE_IDIOM(). Currently the two values for this are UIUserInterfaceIdiomPad and UIUserInterfaceIdiomPhone.
The "easy solution" you describe is basically how iOS loads Universal apps.
There's no other real way around it. You'll have to merge your two projects into one again to do what you want.
The first problem will be that some (many?) names of classes will be common between both projects. You can save yourself some pain by using the "Refactor..." functionality in Xcode to change the names of the classes in one project (say, your iPhone app, since it's older) before you merge them together. The second problem will be your Info.plist; you'll need to ensure that the correct "Main nib file base name", the correct supported interface orientations, icon files, and so on are set to correct values for both iPad and iPhone respectively.
Please bear with me, this isn't a programming question per se but a question about releasing for the App Store.
I have an App on the store that is a universal binary, with a separate UI for the iPad. I've been creating some new features and working exclusively in the iPhone version. I've been rethinking my iPad UI because I feel like it's kind of poor and could be more well done. I'd like to branch off and create a specialized iPad only version and abandon the iPad code in the current universal binary, and instead just target the individual platforms instead of both.
The reasons are as follows:
I want to be able to do a release with new features without having to commit to working them all in on the iPad version of the universal binary.
I want to distinguish the iPad version from the iPhone version.
First, I want to know if this is even possible. Second, I want to know what kind of fallout is possible from something like this. I remember two years ago when Tweetie 2 was a new bundle and the general public mostly whined about having to pay again. My app is much smaller than Tweetie 2 and I don't have a ton of users. In fact, I don't use any analytics to discover daily use, feature use, or anything.
Have any of you ever done something like this?
Thanks for your time, and please don't flag.
That would really suck for iPad-only users who bought your program.
What you could do is leave the existing app out there as version 1. Don't upgrade it.
Release version 2 in separate iPhone and iPad flavours. No existing customer gets left out. You get to split your releases. If your app is truly good then people will pay again for the upgraded version.