I understand that Gluon shows nag screen for free users as per the documentation on the websiteand removes the nag for paid. "Licenses are validated online once per application install."
Say, a developer purchases a paid subscription, builds and releases the app in 6 months. After the app is released there wont be development for a long time.
So, the developer cancels the paid account and goes back to free. The app is already released and in stores and on many users devices. Now, after the six month, will the nag screen start showing again for new installs and current users?
I have asked technical support about this problem and their answer was:
Hi Ahmed,
Thank you for contacting us.
Any apps deployed to App Store or Play Store with the license will continue to work without nag screen even after the license expires. Only, if you want to make any changes(development) to the existing app after the expiry of the license, the nag screen will be shown again.
Hope it answers your question.
Related
I am considering purchasing a license to create mobile games with game maker studio 2. They have recently updated from a perpetual license model to a subscription model. However, it appears that it is still possible to buy a perpetual license if it is purchased through steam. I know that it is possible to link a steam account to a yoyo games account. But, is it possible to get a perpetual license for mobile development on steam, and then transfer it to my yoyo games account so that I can develop for mobile without using the steam version of gms2?
You can link a Steam account to YoYo Games account on the dashboard to have access to those licences without having to run GameMaker via Steam;
As per FAQ, if you buy a permanent licence, you keep it, including the current Steam licences (which have not been updated to subscription model yet).
Our app has been in the Play Market for 4 years.
Before the last build, we added AppMetrica in the app:
implementation 'com.yandex.android:mobmetricalib:3.13.1'
implementation 'com.android.installreferrer:installreferrer:1.1.2'
implementation 'com.yandex.android:mobmetricapushlib:1.5.1'
The project with these instruments was successfully uploaded into the Play Market without any notifications (errors or warnings). In a few weeks after that, I made minor changes in sending reports in the AppMetrica and received the following notification from Google:
"We reviewed XXX, with package name XXX, and found that your app uses software that contains security vulnerabilities for users. Apps with these vulnerabilities can expose user information or damage a user’s device, and may be considered to be in violation of our Malicious Behavior policy.
Below is the list of issues and the corresponding APK versions that were detected in your recent submission. Please migrate your apps to use the updated software as soon as possible and increment the version number of the upgraded APK.
Vulnerability TrustManager You can find more information about TrustManager in this Google Help Center article."
We don't use TrustManager and his classes in the project.
What can be the possible reason for rejecting? Is it possible that this rejection was made by mistake? How can we find out what is the reason for that? Can AppMetrica cause this setback and should we stop using it?
Also, in the rejection text they said you can set up the network config (https://developer.android.com/training/articles/security-config) in the app -- how can it help?
We are fighting this trouble for two weeks and we hope for your help
I am interested in creating a desktop application using HTML5+webkit, and I'd like to be able to build a stand-alone executables for various target platforms like a .exe file for Windows and a .dmg image for Mac OS. I have played around with node-webkit, which seems nice except for the packaging / distribution portion. I also stumbled on TideSDK, but that project seems to be inactive. For example, the latest release I saw was a beta from November of 2012. Yet, it seems the core developers have switched to developing TideKit instead.
Does anyone here know if TideKit is intended as a replacement for TideSDK? Is TideSDK going away? etc.
Well, TIDE is now officially a dead project. I just got this email about 15 minutes ago.
TideKit.com and TideKit have been discontinued.
TideKit was software for developing apps for all platforms
simultaneously with a single base of code written in JavaScript.
The scope and complexity of the product made it difficult to
assemble the platform all at once. This stemmed from a holistic
approach to app development for all platforms. While creating a
platform for JavaScript developers, much of the core engineering is in
a variety of lower level languages that affect the speed of
development. We considered delivering parts of our platform as we
reached milestones, but this was not suitable for the start of trials.
We were widely criticized for not revealing our technical innovation
in advance of our release. In a competitive environment, revealing
advantages as you go can also mean assimilation as you go. We had
already witnessed how quickly our technical advantages could be
assimilated by competitors to our open source TideSDK product.
Therefore, we held back with a view of delaying the duplication of
features by competitors, increasing our technical barriers and working
to protect our IP and business case until we felt we were ready.
In a startup, we talk about a Minimum Viable Product (MVP). In our
case, our minimum viable product was much larger and more difficult to
achieve. In total, approximately three years of research and
development was committed with multiple developers working greater
than full time hours. A factor that extended the development was an
expansion of scope that aimed to lower friction in the app development
process.
In Feb 2014, we created a system to queue developers with
reservation system for the earliest possible access to TideKit. Our
goal was to provide an early trial when it became available. Since the
development itself was complex, we could not provide a date when
ticket holders could start the trial process – but it would be
following our betas, then moving forward as we scaled the platform.
We were clear with our language on the site concerning reservations.
As a result, we expected little confusion about what was being
purchased, our expectations of timing to market, or the terms of
purchase for a reservation ticket. Purchasers were not paying for our
product at this point, but for their position in a queue for a trial
of our new technology. We also included a refund policy to ensure the
terms of purchase for your ticket were available. The wait has been
long, but not nearly as long as other difficult engineering challenges
including Myo that pre-sold their product and were also delayed before
successfully rolling out.
Throughout the development cycle we provided updates of our status
via posts roadmap page, email to our ticket holders and communications
on our social channels. We did our best as a team to open ourselves to
questions and maintain a social presence.
At the end of May 2015, we communicated our strategy to execute a
series of focused betas that would have seen the platform revealed
publicly and incrementally. We were at a stage that parts of the
platform needed developer feedback as we rolled these out
consecutively.
In the days preparing for our first public beta, we recognized the
extent to which our brand had been poisoned by our timing to market. A
campaign of negativity that had begun several months earlier with
followers and ticket holders had taken its toll on our team, brand,
and business.
We believed the beta releases would soon bring an end to the
negative talk. On July 8 and 9 we faced further eruptions on social
media that reached the tipping point. With the discussion no longer
about the product nor its future, this was far more serious.
We failed to bring the product quickly enough for you. As a result,
we came to the serious decision to discontinue TideKit and dissolve
our company.
We wish to thank everyone involved that worked on the product and with
our team. This includes businesses, entrepreneurs and supporters of
our vision for app development.
Your TideKit Team
you are right, TideSDK is aging and pretty inactive today. And you're also right, we as a core team completely focus on TideKit now. TideKit is the future!
If you want to know the full story about why we stopped working on TideSDK and started TideKit, I recommend you to read our first Q&A. There you'll also find an answer about how we compete with node-webkit:
https://blog.tidekit.com/post/your-questions-our-answers-01
We've just reached the highest HTML5 score any app development platform ever achieved. If you want to know more about builds, like the ones you mentioned for Windows and OS X, you should read this
Desktop Builds
https://blog.tidekit.com/post/from-a-desktop-perspective-tidekit-for-tidesdk-developers
There is a new kid on the block for this sort of projects: atom-shell Based in nodejs and used to create the great Atom editor
Technical differences with node-webkit: https://github.com/atom/atom-shell/blob/master/docs/development/atom-shell-vs-node-webkit.md
Presentation at JSLA about "Native NodeJS Apps": http://vimeo.com/97881078
If you look at this blog post, they talk about how unsustainable the economical situation is
http://www.tidesdk.org/blog/2013/04/11/tidesdk-in-numbers/
and I can't find the tweet that was stating the reasons behind the transition from one project to another. But I guess that the blogpost speaks for itself.
Anyway, I'm delivering a project written in node-webkit ( because I starded on Tide but for the obvious reasons I had to switch ) and I'm using grunt for packaging and in the end is not that bad.
Electron (http://electron.atom.io/) is the new way to go.
I also had an app running on TideSDK (https://github.com/vinyll/worktimer.titanium) and I'll have to migrate it to Electron.
Does Apple have a way to find out that an application already is in the Cydia store when I try to submit it to the AppStore?
For Example, if I change the name and icon for an application that appears already in Cydia and try to submit it to AppStore? Can Apple find out?
Is it possible that Apple collects statistics about jailbroken phones and their applications and has this data in its db (by sending it in some background process)?
First of all, I'm assuming that the existing app on Cydia is your app. I certainly don't condone stealing some other developer's intellectual property, just because they released a Cydia store app.
To answer your questions:
Yes, of course. They can just use Cydia themselves and search for your app's name. They could certainly also just use a desktop browser and search for your app's name, to see if there is any obvious copyright infringement. While I don't think Apple feels obligated to do this, I have had apps rejected (before ever being released) because Apple believed my client was violating some other 3rd-party's intellectual property. This kind of search could also turn up a listing in a Cydia store repository. So, it is possible.
I very much doubt Apple would find out about this. Simply renaming the app seems likely to avoid any problems.
I'm not sure I understand the question. Are you asking if iOS checks to see if the device it's running on has been jailbroken, and if so, reports that status back to Apple? I don't know, but millions of users run jailbroken phones, and I haven't seen Apple try to disable their functionality.
I have had clients release apps on the Cydia store first, and then try to release them on the iTunes App store. Although none of those have been approved by Apple, they have been rejected for private API usage, or violation of Apple's Human Interface Guidelines, not because they already existed on Cydia.
I suppose that if an app was released on Cydia, because it used private APIs, and then iOS later added that capability in public APIs, then you could try to submit it to Apple.
I don't work for Apple, so these are only my guesses based on personal experience.
It depends on the repo you put it on. If you put it on a personal repo im sure you will get away with it. It depends on what your app does, it shouldn't really matter to apple as long if it doesn't mod, exploit, change, or use a private API or do any illegal acts/violate copyright it should go right past apple's appstore. They monitor and last time I heard check code manualy.
According to http://mdbf.codeplex.com/:
"Due to the organizational restructuring of the team that developed and supported the Mobile Device Browser file, we will no longer have the resources to support and update this CodePlex project. The team will be providing two more releases – one on the 27th July 2010 and the final release on the 24th August 2010.
We would like to thank everyone who used our product over the past year and a half. We would also like to thank everyone who contributed to the discussions and raised issues on our data."
Does this project live on someplace else or is there an equivelent project?
51degrees claims to have a replacement, but it isn't made in the same way (via .browser definition files).
MDBF is still hosted on codeplex though - they reopened it by demand, but there isn't any promises of any updates that could occur.