My MacOS application have a child process in its resources. I launch it up by NSTask.
In local debug, everything works well. But when I upload it to AppStore, Apple told me that my child process binary need a sandbox.
Ok, I set a sandbox to my binary, but new problem came up. The process can't run with NSTask, and the error code is 4, which means EXC_BAD_INSTRUCTION.
All the thing I found is my binary need inherit its sandbox from the parent. I set these entitlements:
com.apple.security.inherit : true
com.apple.security.app-sandbox : true
Whatever, the problem still exist.
My app content is like this:
Contents
- MacOS
- mainExecutable
- Frameworks
- theFramework
- Resources
- theToolBinary
Their relationship is:
theToolBinary need theFramework to work. theToolBinary built on CommandLineTool and signed.
So, is the "com.apple.security.inherit" not working any more? Or what's wrong with my project?
Related
I work still view month on a project with RapidClipse 4.0
I deployed on the production server several versions of the project war files. Everything worked fine.
After the last deployment I got a blank screen after loading the application URL
For the server I use a docker container with following setting:
Apache Tomcat/8.5.43, JVM: 1.8.0_222-b10, 3.10.105, amd64
My first thought was: "ok you did something wrong in your code.. turn back and every thing is fine.... :-((
It wasn't !!
I used several versions which runs fine befor.
I stopped the application, redeployed it and deleted it.
Then I deployed an older version....and once again a version older..a.s.o
Non of the versions which worked fine befor did work again.
I got every time the same result: after loading the application a blank white screen.
So far so bad:
I tried to look into ../conf/server.xml if deployment parameter is set correctly:
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
looked fine!
I enhanced the cache by:
$CATALINA_BASE/conf/context.xml added following code:
<Resources cachingAllowed="true" cacheMaxSize="100000" />
also without success.
I tried to look in catalina.out: There is still nothing helpfull:
14-Aug-2019 20:29:21.087 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/RC_07.war]
14-Aug-2019 20:29:31.190 INFO [http-nio-8080-exec-6] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/RC_07.war] has finished in [10,102] ms
after debug in browser I got following:
257ms Processing time was 134ms
257msReferenced paintables: 6
283msEstablishing push connection
300msCould not load theme from http://myIP:8888/RC_07/VAADIN/themes//styles.css?v=7.7.13
310msPush connection established using long-polling
I searched also in the history of the docker container an found that this problem (300ms....) still persists from beginning, over all versions I deployed before.
Out of this, I assume, that this could not be the reason, too.
Or am I wrong?
I searched around this VAADIN Problem and found a lot, but I was not able to solve it. The styles.css file are still in place on the server.
I am wondering on ..../VAADIN/themes//styles.css...
the double slash in error message.
But in my code I couldn't find similar.
Also the buildpath in eclipse includes the folder structure like expected.
Now I am at the end!
I am confused, how I should go ahead to figure out the reason for this behavior, or much better to fix it.
Any idea/ help would be welcome!!
Thank you in advance
rgds
OpaHeinz
After long research, togehter with RapidClipse support we found the solution.
I had two issues:
1) unknown how, we assume, that there was an error in the MainUI xml file.
After resetting with and high of view and layout, and turning back to setting before,
the page elements were visible again in design view.
2) there is a parameter for the theme under MainUI properties - misc -
This parameter was set, but without content. This results in a code line: this.setTheme("");
After resetting this, a deployment was possible like before.
Everything is fine now.
Thanks again to RapidClipse support.
I built an Electron app and I am now looking at how to distribute it.
I went with electron-builder to handle packaging etc.
For a bit of context, as a web developer, I am used to continuously deploy web apps on a web server but I have a hard time figuring out how to distribute a packaged one in Electron.
In electron-builder docs there is a brief mention about testing auto-update:
"Note that in order to develop/test UI/UX of updating without packaging the application you need to have a file named dev-app-update.yml in the root of your project, which matches your publish setting from electron-builder config (but in YAML format)"
But, it's rather vague...
So I actually have two questions:
1. How do I actually test the auto-update flow?
Do I need to actually publish a new version to trigger an update locally? Seems pretty unclear, it would be like developing against the production server.
2. Is it possible to have a fallback for unsigned code?
I don't have yet any certificate for code signing. So the OS/app will block the auto-update. But, I'd still want to tell the user that an update is available so they can go and download the app manually. Can I do that? (going back to point 1, I'd like to be able to test this flow)
I've just finished dealing with this. I also wanted to test against a non-production server and avoid having to package my app each time I iterated. To test downloads I had to sign my app, which slowed things down. But it sounds like you just need to check for updates. Which I think you can do as follows...
I created a dummy github repo, then created a a file dev-app-update.yml containing:
owner: <user or organization name>
repo: dev-auto-update-testing
provider: github
The path where this file is expected to be defaults to a place you can't access. Thankfully, you can override it like so:
if (isDev) {
// Useful for some dev/debugging tasks, but download can
// not be validated becuase dev app is not signed
autoUpdater.updateConfigPath = path.join(__dirname, 'dev-app-update.yml');
}
...that should be enough for your case -- since you don't need downloads.
If not, here are some other tips:
you can change the repo setting in your electron-builder config to point at your dummy repo then package your app. This will give you a packed, production build that points at your dummy repo -- this is how I did my download testing (though I have a cert, and signed my app)
you should be calling autoUpdate's checkForUpdates(), but if checkForUpdatesAndNotify() gives you a useful OS Notification then you should be able to set autoUpdater.autoDownload to false and end up with what you need.
Lastly, it sounds you could skip autoUpdater, since you won't be using the download feature anyway. Instead you could use github's releases api, assuming you use github to host your release. If not then your host should have something similar. Use that to check for updates then tell the user from within your App (could present them with a clickable URL too). If you want OS Notifications electron has a module for that.
We're using electron-updater with GitHub as a provider for auto-updates. Unfortunately, it breaks a lot and the electron-builder team doesn't support these issues well (1, 2, 3) (from my own experience, but you can find more examples on GitHub).
One way to test updates in dev mode:
Create a build of your app with an arbitrarily high version number
Create a public repo and publish the above build
Create a dev-app-update.yml next to your main entry point and configure it for the repo above (see)
In your main entry point:
import { autoUpdater } from "electron-updater";
...
if (process.env.NODE_ENV === "development") {
// Customize the test by toggling these lines
// autoUpdater.autoDownload = false
// autoUpdater.autoInstallOnAppQuit = false;
autoUpdater.checkForUpdates();
}
Then when running yarn dev you should see something like:
Checking for update
...
Found version 100.0.0 (url: <>.exe)
Downloading update from <>.exe
updaterCacheDirName is not specified in app-update.yml Was app build using at least electron-builder 20.34.0?
updater cache dir: C:\Users\<>\AppData\Local\Electron
New version 100.0.0 has been downloaded to C:\Users\<>\AppData\Local\Electron\pending\<>.exe
And it should install when you close the dev app.
This should give you some certainty but we still ran into issues in production. If you want to be sure, play through the full update flow with a test repo but packaged production apps just as you would do with the live one.
This used to work for me, but now whenever I attempt to "Run in Simulator" with any of the iPhone or iPad types selected, I instantly get the console message
2013/10/1 10:4:48 Error: Script error. (URL: , LineNumber: 0)
I am working in the latest version of Chrome. Any help would be appreciated!
Just so that other users are aware, you can get that error on almost any problem in Mist and identifying the cause usually requires that we (I'm part of Icenium team) look into the specific project. In this particular case the problem was caused by missing App_Resources folder, which blaster has removed from his repository prior cloning it in Icenium. Generally an Icenium project should be able to function without this folder and we would fix this for the next version.
I am trying to configure my app to support push notification, but keep getting this error:
Failed to get token, error: Error Domain=NSCocoaErrorDomain Code=3000 "no valid 'aps-environment' entitlement string found for application" UserInfo=0x1f818fc0 {NSLocalizedDescription=no valid 'aps-environment' entitlement string found for application}
I did enable my app to support push notifications (only for development at this point).
I did create the provisioning profile AFTER enabling the push notifications.
My bundle identifier is the same as appears in the profile.
In my profile file there is a string: aps-environment
I made sure that in both project and target under the "Code signing identity" section ALL the values are selected to be my provisioning profile.
Any more ideas? Thanks.
In my case, the stuff in my provisioning profile:
security cms -D -i ~/Downloads/spolskyDevelop.mobileprovision
...
<key>application-identifier</key>
<string>P5GM95Q9VV.com.dca.spolsky</string>
<key>aps-environment</key>
<string>development</string>
Was different than the stuff in the app that was actually built (you can find out where it is built by looking at Xcode's Logs tab)
codesign -d --entitlements - '/Users/drew/Library/Developer/Xcode/DerivedData/spolsky-bdbtdfjeeywhqzccpmmceqvnhgtm/Build/Products/Debug-iphoneos/spolsky-ios.app'
<dict>
<key>application-identifier</key>
<string>Y2X6Z7Z2GR.com.dca.spolsky-ios</string>
<key>get-task-allow</key>
<true/>
<key>keychain-access-groups</key>
<array>
<string>Y2X6Z7Z2GR.com.dca.spolsky-ios</string>
</array>
</dict>
This was true even though the "Currently Matches" hint text under Code Signing Identity was indicating the correct provisioning profile--weird, huh? To make a weird story weirder, the correct provisioning profile was being installed on the device when I ran, (Settings->General->Profiles) leading me to believe the provisioning profile was right--but it was falling back to a wildcard ID when the app was actually launched.
The clue was the difference in the output of these two commands:
Y2X6Z7Z2GR.com.dca.spolsky-ios vs P5GM95Q9VV.com.dca.spolsky
When I made the bolded part match, the italicized part changed to match automatically. In addition, the output of security and codesign were in agreement, and no more aps-entitlement error.
My guess here is that XCode was using a wildcard-style match on my non-wildcard ID. ("spolsky" is, after all, quite nearly "spolsky-ios"), and this explains the "Currently Matches" output. But something in the build chain is more strict about this, so it falls back to an actual wildcard ID during the build.
The problem is due to current Provisioning Profile does not contain APNS information, as the Provisioning Profile is created BEFORE creating the APNS certificate.
Therefore, to solve the problem, create a new Provisioning Profile & select the Provisioning Profile in Xcode will clear the error.
I had this same problem after push notifications were already working on my device. Seemed like Xcode cached something incorrectly so refreshing it fixed my problem:
Xcode -> Preferences -> Accounts
View Details for your Developer Account
Just click Refresh for the Provision Profiles a few times. I was seeing these change with each refresh. Keep refreshing until they stop changing.
i got this error and did not create a new provisioning profile; created a new one and then had to restart xCode but works now!
Be aware that the bundle identifier must match the provisioning profile in a case-sensitive manner. I had something like com.FirstLast.appname when it should have been com.firstlast.appname. Well, that kept me busy for quite a while.
I fixed this problem by enabling push notification capability.
Select Project > Target > Capabilities > Turn On Push notifications
If this problem happened suddenly after upgrading to Xcode 8 you might find a warning in the capabilities screen that'll allow you to fix this automatically:
Select Project > Target > Capabilities > Turn On Push notifications
Product->Clean did it for me. Hopefully it does it for someone else.
I ran into this in what's possibly a non-frequent use case. I'm working with Xcode 6 and iOS 8. I was creating a series of entirely new app projects, and attempting to re-use the same bundle ID, so as not to need to go through all of the portal-side setup again. This too was just for sandbox testing.
I would find that, while the setup and registration would work fine for the first app, if I deleted that app from the device, set the same bundle ID for the second app, and then attempted to register PNs with that app, I would get this error.
My solution was to:
Remove the associated provisioning profile from the device.
Remove the associated provisioning profile from Xcode.
Close Xcode
Double-click my downloaded .mobileprovision file to install it back into Xcode
Open the project and deploy it.
This approach seems to jar loose whatever previous state was there, and I'm able to register for PNs with the new app / same bundle ID.
For those who got this error in ios 10, you can try following steps:
1.clean your project.
2.and check Targets -> Capabilities -> Push Notification.If it is off,On it.
And problem will solve.The above steps help me to get rid off this problem. Hope it will helpful to someone.
New provisioning profile worked for me. Make sure to use a Developer profile if you are in development (don't use Ad Hoc). It was fine after that, no idea why the old one stopped working right.
I am sorry for posting so many questions, but getting this to work has been incredibly painful, even tho Testflight makes it much easier
Invalid IPA error: The APS environment in your embedded.mobileprovision and your binary don't match
I figure this has got to do with my Apple Push Notifications. I am using my distribution profile across all my settings. My app has been configured to both development and production.
What could the causes of this error be?
As a side note, I have been working on this for the entire day, and I get stuck at one thing after the other, esp involving static libraries and xcode4. Am I really bad at this, or does Apple really make it so hard?
I think it was an xcode bug. Here's how i solved it, and maybe it can be useful for some users in the future. Including my problem solving steps for reference:
i changed the entitlement file to aps-environment = production. No go, still different between the 2 files.
i changed ALL my settings (debug/not) to the distribution profile, just to be sure
I built it again, and checked out the embedded.mob and binary as you suggested
No go again.
I went nuclear - deleted all my profiles, downloaded only the distribution build i needed
here is when it became interesting - i could not build it on debug (expected), but i was having the same problem of "profile not found" even when i was in ad hoc archiving mode. Surely that means that there remains a reference to the developer mode even when i was trying to archive it (given that i have already changed ALL my settings and deleted all my other profiles)
So i digged up project.pbxproj, and found the offending line that was still trying to access my development profile in ad hoc build. I changed it manually, and bingo, things worked as per expected
End of the day, i am surprised why this would happen. It seems like an xcode 4 bug. Normally it is my fault when these things happen, but this seems arcane enough (plus i had so much trouble with xcode 4 for a few other things).
Solved with help from the amazing Testflight team!
http://support.testflightapp.com/discussions/tools/17-invalid-ipa-the-aps-environment-in-your-embeddedmobileprovision-and-your-binary-dont-match
Also, particularly if the target you're archiving was based on another target, double check that your target's "Archive" Scheme is based on the correct Build Configuration of Build Settings.
In Xcode 4.2 next to the run menu, click on -> Edit
Scheme
Click on the 'Archive' button in the left drawer
Look at 'Build Configuration
For Testflight, I replicate my Release Build Configuration, and rename it 'Ad Hoc' for just this purpose, specifying my Ad Hoc provisioning profile and whatever else needs to be in there. If you've gotten this far, I presume you've already done that, but for posterity, I figured I'd mention it.
I ran across this error before as well, so follow these instructions for this to work:
Create a provisioning profile for your app and add the devices to it of the people who should test it.
Build your application using that provisioning profile you just created and export it as an *ipa.
Upload it to TestFlight and select the devices that you want to test the app on.
Many people miss step 2, (so did I) and that's essential for it to work. So give it a try! :)
Replying this question, in case someone bumps onto this while uploading an air mobile app.
Make SURE you check the Entitlements element in your app.xml.
<iPhone>
<InfoAdditions>
<![CDATA[
<key>UIDeviceFamily</key>
<array>
<!-- iPhone and iPod touch devices -->
<string>1</string>
<!-- iPad devices -->
<string>2</string>
</array>
]]>
</InfoAdditions>
<!-- This part below.. -->
<Entitlements>
<![CDATA[
]]>
</Entitlements>
My Entitlements looked like this back when I got the error:
<Entitlements>
<![CDATA[
<key>application-identifier</key>
<string>QFY9MVY9K8.com.somethingHere.anAppName</string>
<key>aps-environment</key>
<string>development</string>
]]>
</Entitlements>
This is how it looks now:
<Entitlements>
<![CDATA[
<key>get-task-allow</key>
<false/>
]]>
</Entitlements>
This error was caused because
I used a DIFFERENT ID in the <key>application-identifier</key> than the one in my provisioning profile.
I used development key instead of production in the <key>aps-environment</key> part.