Base SDK Missing - ios

I get the "BASE SDK Missing" when re-opeing projects. (I got the latest build of xcode, and latest SDK installed.)
It seems to be happening when I quit a project, (not exiting xcode), and re-open the project after a while. I have tried both, with and without my iPhone plugged in. I have tried to fix the problem like described here, but it does not help for me. - It just makes it even worse! (unrecognizable SDK)
The only way I have managed to get it back to normal, is to do a manual re-boot of my mac, plugged in my phone, waited until it has checked my iPhone, and then, opened xcode. Time consuming and annoying!
Why does it happen and what is the trick to fix this?

Your recent upgrade of Xcode likely removed the earlier SDK that your project was set to use. There are a couple of solutions for the problem. The most simple solution is to always select the "Latest" SDK in your project's settings and not select a specific option. You may be uncomfortable with the idea and want to run your app on an older device but it's important you understand that all of the newer SDKs can generate code that works on older versions of iOS. There's a separate hard to remember option for setting the deploy target. (It took me a while to learn how/why to use this but it's well worth it.)
The second option is to actually find a version of the SDK that your project is set to and attempt to reinstall it. I suggest going this route only if necessary as it's not guaranteed to work in each case. Older SDKs may or may not work in later versions of Xcode (Eg. SDK 3.0 might not work in Xcode 4.3.2) due to major changes in the toolchains. Tools like gcc/gdb are deprecated in favor of llvm/lldb. Still, you may have a valid reason for using an older SDK. You may have to fix a bug that is present only when using the older toolchain or you may need to reproduce a problem that only happens with builds generated from your build server. In many of these cases it might be easier to upgrade where the problem occurs (Eg. upgrade the tools on the build server) or downgrade your dev environment. (Install an older version of Xcode.)
The reasoning behind the frustration is that Apple highly encourages rapid adoption of it's latest tools and technologies. It creates a better product as the dev community is forced to stay current and competitive while the users are forced to maintain upgrades to ensure apps continue to work. This is in contrast with the traditional model of backward compatibility allowing developers to support revision -n of a product/platform. It is also great for business since rapid adoption of the latest often encourages purchase of newer hardware and products to get the best experience. The rapid adoption ensures the more robust software along with bug fixes, enhancements make it to the majority of consumers overall increasing their penetration in the market.

You have to set your target and project's base SDK to "Latest" and not an explicit option. If you choose one explicitly it seems to break if you update xcode versions.

Related

How to update an older iOS app version when a newer one is already out?

Let’s imagine I have an iOS app. In version 2.0, I added a bunch of new features, but to implement them, I had to drop support for an older iOS version which is still in heavy use (remember, it’s a hypothetical scenario).
Later, I discovered a super critical bug in version 1.0 of my app that needs to be patched.
What are my options in terms of distribution?
It seems that it’s not possible to release version 1.0.1 if version 2.0 is already on the App Store. Adding back support for the older iOS version and fixing the bug in 2.0.1 is not feasible because that would require removal of the new features.
The problem here is that I can’t think of a way you could submit a version that updates version 1 without letting your version 2 users download it. So if you want to update version 1 you will just have to bite the bullet and meld your versions together. Use availability so that the new features are not present for your version 1 users.

How do I check the stability of multiple beta versions of software that all needs to build together?

My team is developing an iOS app with ARKit in Unity. Until the release date in September, we have to rely on beta versions of Xcode, iOS 11, Unity, and the Unity ARKit plugin. We lost almost a day of development time trying to figure out what was breaking, which turned out to be these beta version issues.
I want to be able to know what combinations of different versions of each system work so we can quickly identify issues. For example, something that says "the ARKit sample app from Xcode 9 beta 2 builds with Xcode 9 beta 4 but not vice versa" and "the Unity ARKit sample app does not build with version 2 of the plugin and and Xcode 9 beta 4."
I've heard tools like Jenkins or Travis mentioned but I don't know what they do or how they get put together.
We're a team of four college students with no industry experience beyond internships, so perhaps that's relevant to making sure this isn't an XY problem.
[Lastly, apologies if this is not the right forum for the question. I'd be happy to close this and post somewhere else.]
Unfortunately that's the nature of the beast when using beta tools and API's. Things will break and change. You are on the bleeding edge as they say, so when you experience an incompatibility you may very well be the very first person to 'uncover' it. Be sure to file bug reports as you discover those and be active on forums and communities as much as possible.
Your best source of information is from the vendors themselves. Release notes specifically are a valuable piece of information. For Xcode and Apple technologies, go over to the downloads section of the developer portal and read the release notes of the relevant tools and platforms:
Take a look at the known issues:
Same thing for Unity or any other tools:
I'm not sure how build tools such as Jenkins will help you out. You might be able to set-up a working build pipeline with specific versions of the tools in question. But seeing as how these tools and API's are in constant flux (and this stage, for good reasons of course) those pipelines might get deprecated very quickly...

Is there a way to just apply changes in iOS simulator without rebuilding the whole app?

I'm asking because this is a feature of android studio and was wondering if xcode or an external thing had something similar?
Yes, there is:
https://apps.apple.com/app/injectioniii/id1380446739 or from here https://github.com/johnno1962/injectionforxcode Also, I think you can get it through Alcatraz too if you have it on your XCode
Also, another tip if you have not made any changes and just want to attach the debugger and run the app without building you can do: CMD+Control+R which will run the app instantly without building.
It's would be very useful feature for development, if the same would be possible with upcoming version.
But unfortunately, as of now, with current latest version of Xcode, it is not possible to apply source code changes without rebuilding an application.
Nice question, it deserves space in Apple Bug Reporter...

Test code on older iOS version

I have a piece of code that has a specific behavior under iOS9. However, I know that it didn't always behave in the manner it does under iOS9. I wanted to run it on previous versions, so I could discover when the behavior was fixed.
Unfortunately, Xcode 7 seems to only support simulators back to iOS 8.1.
Short of reinstalling previous iOS versions on an actual device, is there any way to install and run simulators for earlier iOS versions? Or, is there another method to accomplish my goal?
EDIT
This edit is to explain why I do not think this post is a duplicate, as indicated in the close request. Hopefully, in explaining why it is not a duplicate, it also better explains the issue and hopefully results in a solution.
#JeremyHuddlestonSequoia - Thanks for the input. That post has really good information. However, I don't consider this a duplicate for several reasons.
I already knew that information, and it didn't keep me from asking this question. So, for whatever reason, it does not give me what I'm looking for.
I don't consider questions to be duplicates if one is talking about the behavior of a beta release and the other is talking about the behavior oaf a production release.
I don't want to know how to install older simulators. I want to know if there is another way to run the simulators outside of the Xcode preferences. I think it is completely absurd that Apple have determined that nobody in the world needs to run older simulators with newer versions of Xcode. Thus, I'm looking for some alternative to the solutions in the possible duplicate question.
If there is no other way to install the simulators, maybe there is some online resource that has simulators available going back to iOSx.y that may be accessed, even if that access is for-pay. Or, maybe there is some online resource that runs stuff on actual devices, and I can submit my code to that resource.
Maybe there is some other way I haven't thought of for me to get the answers I am looking for. Basically, I want to know in which exact release of iOS a specific behavior changed. Thus, I want to run a small piece of code on different iOS versions until I witness the difference.
The fallback is to reinstall each OS on a device. Maybe someone knows of a way to do this programmatically so I can kick off the process and have it run on it's own. There are a bunch of possibilities, but I am unaware of what's out there to deal with this issue.
I was hoping that there was some way to install older simulators. The first paragraph of the original post explained my ultimate goal. The last sentence of the original post summed up the difference between this post and that post.
I'm not just looking for a way to install older simulators. That would be a WONDERFUL way to accomplish my goal. I'm looking for a way to test code on older iOS versions. Using the simulator is one possibility... if there is some way to convince Xcode to do it on something older than 8.1.

Zeos 7 Failing to install

I have installed the Zeos 7 Beta on my own machine but it fails on my client's laptop. We're both running Delphi xe2, his is Entreprise, mine is Pro. His machine is running 64-bit windows 7, mine is running Window 7 32-bit.
When I do Compile all on ZeosDbo or ProjectGoup16 it seems to get through ZCore.dpk but then shows 2 fatal errors:
ZCore.dpk(1) E2225 Never-build package 'ZCore' must be recompiled
ZParseSQL.dpk(33) E2202 Required package 'ZCore' not found
This is production code we are working on, so I hope we can find a solution and get back to working on this
Zeos forum thread: http://zeos.firmos.at/viewtopic.php?t=3633
That is one error, the 1st one. The second is merely post-effect.
Perhaps you can do better than downloading beta ZIPs: until they have mature release you just can download each day "nightly" changes by version-control tools, like Git or SVN or whatever Zeos team is using.
Such errors are usually quickly fixed (they are simple) but long released(they are so moot that no one would bother making release for them).
Just open http://zeos.firmos.at/portal.php and read where to get most instant updates and how to report problems.
Actually - there it is, http://svn.code.sf.net/p/zeoslib/code-0/trunk/
Install TortoiseSVN and be on the edge until 7.0.1 or 7.0.2 final release
The page also says: Please report bugs for this version to our brand new bugtracker on sourceforge https://sourceforge.net/p/zeoslib/tickets/
Please do. Open Source is about participating. At least participate by registering bugs.
About the essence of problem read official documentation and "See Also" section.
Someone should decide about package binary update strategy. And the decision should be kept for all packages (okay, you can mix it in some conditions, but that is not to be suggested). So basically you have three choices:
Make your own decision and put all Zeos packages into the strategy of your choice. That puts the responsibility upon yourself to maintain this fork for a while until you come back to vanilla ZeosDB.
Report the bug to ZeosDB team and ask their suggestion, then change those settings for all the packages as suggested by them.
Report the bug to ZeosDB team and wait until they'd fix it in their SVN and then do SVN Update.
Personally i'd go with 1 option, but i am ready to be FLOSS libraries co-developer.
Option 3 would be the most slow yet the most easy for you.
Option 2... well... i can not see why you should choose that, except for trying to avoid version controls at any cost, which is bad idea per se.
I also suggest you to read http://www.catb.org/esr/faqs/smart-questions.html
That would help you effectively communicate at ZeosDB forums - and you'd have to if you want to be "on the edge" (and if you do not - then wait for public release like 7.0.2).

Resources