My app comes with a quick look plugin.
Currently I'm signing it with the same provision profile as the main app.
Do I need to have separate bundle id and provision profiles for my qlgenerator ?
I've published my app on App Store with a separate provision profile and bundle id for the qlgenerator. It passed the review and seems to work just fine.
So I guess the correct answer is "Yes, you need to have a bundle id and prov.profile for the quick look plugin"
Related
I have a Chrome app that I created with "Create Application Shortcut".
What I need is to open that app with specific url on the same domain.
Example:
chrome_proxy.exe --profile-directory=Default --app-id=xxxxxxxx "https://www.google.com"
Is that possible or any command that achive the same result?
I'm guessing you installed the Chrome app so that the website launches in a standalone window. If this is the case, you can achieve something similar by using the --app command line switch instead.
Eg: chrome_proxy.exe --profile-directory=Default --app="https://www.google.com"
This doesn't strictly open the URL in the existing app, but it does open that specific URL in a standalone window.
Here's the answer what you are looking for.
chrome_proxy.exe --profile-directory=Default --app-id=xxxxxxxx --app-launch-url-for-shortcuts-menu-item="https://youtu.be/dQw4w9WgXcQ"
Using this will work:
chrome_proxy.exe --profile-directory=Default --app-id=xxxxxxxx --app-launch-url-for-shortcuts-menu-item="https://youtu.be/dQw4w9WgXcQ"
It will launch in the special standalone window AND navigate to the specified URL.
Replace xxxxxxxx with the app id (this can be found if you look at the properties of the shortcut it created), but after you create the app this part should already be filled in.
At that point all you need to add is this part:
--app-launch-url-for-shortcuts-menu-item="https://youtu.be/dQw4w9WgXcQ"
Replacing the https://youtu.be/dQw4w9WgXcQ part with the full URL of where you would like to navigate to.
Documentation of the argument can be found here.
Credit due in part to 김보근.
I've enabled a G Suite Marketplace SDK but initially I set the Visibility to "My Domain" so I could test in isolation on my domain. Now I want to set it to Public but that setting is disabled.
Warning: Once you select and save a visibility setting, you cannot change it later. (https://developers.google.com/gsuite/marketplace/sdk)
However I can't even disable/delete that API configuration and recreate it, so I can set it to public.
Is there any way to change this GSuite Marketplace API configuration to Public? (without having to tear down the entire Google Project and all it's API configurations and start over... seems there should be a better way)
Thanks
Try to access your Developer Dashboard and click the edit part of your item. You can check there if you can set the visibility option of your item.
I think once you change it, it will undergo a manual review and you need to wait some time to be approve.
I contacted Google support and confirmed that the only way to resolve this is to create an entirely new app and choose Public the first time you save it. I hope that helps.
We’re starting to use Fastlane for automated deployment, and it’s a very impressive toolset.
One mystery, though:
When submitting a BETA build to Apple’s TestFlight, how do you pass in the Demo Account credentials (username and password)? The docs don’t seem to say.
There seem to be a couple of clues here:
https://github.com/fastlane/fastlane/blob/master/spaceship/lib/spaceship/test_flight/beta_review_info.rb
https://github.com/fastlane/fastlane/blob/master/spaceship/spec/test_flight/app_test_info_spec.rb
And there does seem to be a way to pass in this info for actual App Store submissions:
https://github.com/fastlane/fastlane/blob/master/deliver/Deliverfile.md [see app_review_information]
... but not for TestFlight betas.
How do you do the equivalent for BETA uploads?
Thank you very much!
You need to use Appfile, pilot use it like deliver
Here is the doc.
https://docs.fastlane.tools/advanced/#control-configuration-by-lane-and-by-platform
My Appfile for ex. is:
app_identifier ENV["app_identifierEnterprise"] # The bundle identifier of your app
apple_id ENV["accountAppleId"] # Your Apple email address
team_name ENV["teamNameEnterprise"]
team_id ENV["teamIdEnterprise"]
for_platform :ios do
for_lane :releaseBeta do
app_identifier ENV["app_identifier"]
apple_id ENV["accountAppleId"]
team_name ENV["teamName"]
team_id ENV["teamId"]
end
end
I use .env (a file to set this variables), but you just need to replace ENV[""] with "ValueYouWant"
Hope this helps.
Brand new to teamcity (~2hours), and I ran into a problem. How does one generate or create a "Build Configuration ID"? After searching google and stack, there doesn't seem to be much more than documentation of what it is. Is this something very simple, or can I just make up my own?
When you create a build configuration, it will pretty much get automatically generated from the Parent(s) and Config Name
You can edit this field if you want.
I have one TeamCity project Dac.Test that contains 3 configurations: DEV, QA, PROD.
Also I have some users associated with their Roles. Is this possible to hide / show certains configurations for selected users or groups?
For example: Users associated with group: Testers can see QA configuration, but not PROD and DEV.
There is no way of managing user permissions per-build, this is available on a project level only. You could create a sub-project in the Dac.Test project to cater for this
If you're looking for a way of stopping people from mistakenly running this build, the following approach will work.
This method uses a prompt box that will pop up after you click the run button, it also needs input from the user confirming that they mean to run the build.
No one can run this build by accident
Go to your build configuration in the TeamCity UI
From here, go to Edit Configuration Settings --> Parameters --> Add new parameter
Enter something like 'Confirmation' as the parameter name
Then beside 'Spec:', click the 'Edit...' button
Set up the parameter as shown in the following screenshot:
You will now be prompted and asked for confirmation when you click the run button. The user will have to enter 'YES' in the prompt box that appears, any other value will stop the user from building:
This is best accomplished by using TeamCity's built-in role management. Roles allow you to set fine-grained permissions for users and groups. One potential issue, however, is that roles are scoped to projects (not build configurations). You'll need to create a separate Dac.Test QA project+configuration and provide your Testers the necessary privileges there. You'll also need to make sure that they are stripped of all privileges for the Dac.Test project.