It seems that starting with iOS 8.3, the "iTunesMobileDevice" hack to "HouseArrest" an application folder for reading/writing is broken.
I noticed that some commercial companies mention 8.3 support in there releases notes, but nobody is willing to share what has to be done to fix it.
https://www.macroplant.com/iexplorer/release-notes
iOS 8.3 compatibility - allows read/write access to Documents folder
in apps that have iTunes file sharing enabled
Here is the code that doesn't work with 8.3.
Does anyone have experience with this issue?
EDIT: After digging further, the error is "InstallationLookupFailed". After reading this, apparently, there is no fix. :(
Related
I have a bunch of applications that run fine using node-webkit on Macs and Windows.
(They mostly live on shared Dropbox folders. They read and write to data files in the folder).
I gather node-webkit will not run on Mac Catalina.
So I am trying to figure out how to install and use nw.js
I need the Mac and Win versions of the app to be in the same directory. Multiple users will run their local Dropbox version of the app, and read/write to the shared data folders.
I cannot figure out how to get convert the app from node-webkit to nw.js
I've been unable to find an "idiot's guide" to this.
Any suggestions, or pointers to resources, would be most helpful.
Thanks in advance.
And apologies for posting what is probably a dumb question for most users of this site....
You have to run your app's old source code (node-webkit) with NW.js and fix all the exceptions thrown. You can find the migration guide here.
We integrated with UniData in 2013 using UniObjects for .net and we tested against UniData 7.3. We now have a client on a newer versions of UniData (8.1) and we are having new problems with the integration.
I dug through the documentation on RocketSoftware's website and found the UniObject documents were no longer listed under the documentation for UniData 8.1 and 8.2. I also couldn't find any recent threads via search engine around UniObjects.
"UniObjects for .net Developer's Guide" is listed here:
https://www.rocketsoftware.com/products/rocket-u2/UniData-v7.2
Not listed here:
https://www.rocketsoftware.com/products/rocket-u2/rocket-unidata-v821-technical-documentation
I'm not sure if the documentation just moved and I am overlooking it on the site or if it went away entirely. My suspicion is that it's not supported anymore or won't be supported soon.
Does anyone know definitively that UniObjects is supported or not supported in 8.x versions of UniData?
Any insight around this is greatly appreciated!
Yes, it's definitely supported. I work with an application that uses Uniobjects for integration extensively and it works the same as ever with 8.1 on Linux. The documentation is kind of a mess and keeps moving around, but the functionality is definitely still there.
There were security/encryption changes a few years ago, so the parameters around that are a good place to start looking. There's also a debug flag to check what's happenning - serverdebug.
https://groups.google.com/forum/#!topic/u2-users/okE3-TL_mvE was a recent thread on u2users group, it may be worth asking in that forum to get more responses too. It's a friendly bunch.
While developing a Cocoa sandboxed application, I discovered that if I switched it to non sandboxed, in all the Open Panels of the application, the right click commands (Duplicate, move to trash etc.) do not work any more. I am certain they did work no more than two weeks ago, but I have reverted the project to old commits and the misbehaviour is still there. I tried everything, until I realised that this misbehaviour now appears in all my projects, if I switch them to non-sandboxed. This makes me think it may be some kind of bug introduced in 10.14.2 or something similar. I hope somebody else has experienced the same issue so that we can understand better what is going on. Thanks
P.S. I am using the latest Xcode 10.1 (10B61) and tried on several machines. It is the same misbehaviour.
The OS might be confused by having some contradicting leftover knowledge about sandboxed and non-sandboxed versions of the app with the same version / bundle ID / signature.
Some things to try:
Test the app on a fresh user account.
Delete the app sandbox container from your Home Folder > Library > Containers.
Temporarily change app bundle ID to something new to see if it’s still affected.
I need to locate the OneDrive folder on the user's hard drive for an app I'm working on.
I saw this answer for Windows - Get OneDrive path in Windows - although it is pretty old.
I'm wondering if there is an officially documented way.
For Windows 8.1 and up, you can use the Known Folder API described at http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457(v=vs.85).aspx. For older versions of Windows, you could look at the registry, which is what you linked to It might be helpful although there aren't any guarantees from it.
For Mac, there isn't an officially supported way.
I have an OSX application written in Objective-C/Cocoa using xcode. The application is quite finished, tested and sold on the App Store.
I haven't worked on this application for some time and recently, I rebuilt it using xcode 4.3.3 on my OSX 10.7.4 and I noticed that while it builds just fine, there are some very strange visual glitches when running the application that were never seen before and occasionally, I get EXC_BAD_ACCESS when closing the application. All these seem to be related to the PDFKit framework I am using. I am unable to debug these problems since the glitches are just visual (nothing I can check in code) and EXC_BAD_ACCESS exception comes from internally allocated objects not related to my code.
The code itself haven't changed, I tried previous revisions of the code and they all exhibit the same strange behavior now. I tried running an old binary I have of the application (compiled couple of months ago) and it works just fine. Then I tried building it with previous versions of xcode, down to 4.2.1 (which I know was ok when I submitted the app to the app store) and the problems still occur.
Then I suspected this may be something specific to my environment so I built the project on different machine also with xcode 4.3.2 and OSX 10.7.4. Same results, the problems are still there.
So now I suspect that it has something to do with the OSX 10.7.4 update since this is the last thing that was changed between now and when I was able to produce a good build of the application. I am pretty puzzled to what to do next and how to identify the cause of this problem. I have an old binary that is working fine and I have a newly compiled binary of the same code revision that has problems.
Is there any useful information I can get from the difference of these binaries? What can I do to determine the cause of these problems? What can I try next?
Thanks!
NOTE (update): I stated it above but I want to make sure it is clear. This is a Mac OSX Cocoa application, not iOS.
just reset your simulator then try.
I hope you check the ARC information
go to your project Target set build settings --> Search Paths-->Always Search User Paths Set Yes.
And check your all class variables different from one another.
Xcode--> preferences-->Documentation check installed core Libraries (or) install it
like that
Xcode--> preferences-->Components check required component installed or not
check these things in your project.
Are you sure your customers are not having the same problem? Since you have tested the application on a different machine you probably do not have corrupt libraries installed (unless you did not install from scratch but used some migration tool?), so that is probably not the problem.
Most logical explanation to me would be that your customers also have this problem but they haven't reported it yet. In that case, you probably have a memory problem and there are techniques to attack that.
In any case, eliminate all the parameters that you can eliminate to simplify the problem. Deconstruct the application until the problem does not occur anymore or reconstruct the application in a different project until the problem occurs again.
It sounds like a nasty one, but you'll get there in the end, with patience and perseverance :)
First of all, you need check and verify the build log for suspicious compiler warnings.
For EXC_BAD_ACCESS, XCode analysis will give useful information.
You could try 10.6 or 10.5 (need manual installation) SDK. Or restrict the deployment target to 10.5 or 10.6.
I will answer my own question (since none of the above answers really answer it) so anyone with a similar problem might have a hint. I was not able to understand why exactly this happens but I'm pretty sure this is not a problem with my code but rather some glitch on Apple's side. And there is a workaround.
First, I compiled Apple's sample "PDF Annotation Editor" project on my Lion 10.7.4 and while the functionality is obviously different from my project, it also exhibited similar glitches with the PDFView display that my project does when compiled with 10.7.4
Then I proceeded to building a fresh clean system on new hard disk. Intalled Snow Leopard and upgraded to 10.6.8 and ONLY installed xcode. Compiled my project (the source code always stays exactly the same) and everything works fine. No problems seen in the compiled project.
Updated my OSX to Lion 10.7.4 and xcode 4.3.3, same source code. The problem is there after I compile it. I am pretty sure that if I tried 10.7.3 first, I would not see the problem as I remember it only starts with 10.7.4 but Apple doesn't provide any reasonable way to update to 10.7.3 first or downgrade to it after 10.7.4 is installed (shame on them, not very developer friendly!).
So, the problem appears in 10.7.4.
Then I installed the pre-release version of 10.7.5. This was the only thing that was changed, same source, same xcode. To my surprise, the compiled code works flawlessly now and the problems seen with 10.7.4 are now gone!
So my workaround - wait for 10.7.5 release before working on the project further. Hopefully Apple won't screw it in the future with Mountain Lion. I don't think I am going to try and debug it further or submit a ticket to Apple, going to be a tough case to explain.
Thanks for the responses.