dmitryame

Typical Apple these days. It's not the company we used to love and rely upon any more.

BTW, never've heard of Flutter until you mentioned. Looking into it now. Looks cool, but... It's just been released? I do not want to depend on a bleeding edge solution when everything is at stake (I'm talking about a typical startup execution). I'd give it few more years before seriously considering it. I've seen the solutions that were supposed to take over the world (which never happened). SmallTalk, C++, JavaApplets, RubyOnRails. I'm sure I'm missing a few. While all these are very cool technologies, the "weird" JavaScript stuff is being the most used language in the world these days (whether we like it or not).

Flutter looks interesting, however, the same question applies to Flutter -- this is not a standard Apple's way, as such it may be banned. Why would not Apple decide to ban anything that is not Apple from their store?

"unfair" because they are much cheaper for the employer. If they would cost the same, then if would be fair and the employers would really look at the skills, the talent, and what each person brings on the table. I know, it's really just a play of words. And I'm not advocating for more regulations than necessary. But, I would like the companies that choose to hire offshore to be more honest and come out and say, "yes, we are in penny counting game, and we do not care about quality or what we are building as much".

Not sure what you mean that you are on a look out for talent, if there is no easy and efficient way to get through to you. You may want to think that you get what you need, but believe it or not -- best of the best almost never end up at the big companies.

I understand the pipeline idea, though I think it does not work when the goal is to bring A+ players. A+ players are already employed most of the times. Rarely an event like a layoff happens, that's when they come on a market briefly. They are not going to sit and wait to be processed by the pipelines. And only the B's and the C's ever get through the pipeline to the end. The pipeline idea may have worked during financial crisis, when it was not easy to find a job. But in a current market -- wake up, if you are serious about innovation at a big companies, you are not getting the talent you need for that to happen.

well said, thank you!

I actually do not like either platform's layout system and programming model, nor languages. React Native is actually quite nice IMO comparing to the other two.

haha, I knew it ;)

If you ask me, 3+ incidents of this caliber in the row in one week -- that's not a coincidence. When military ships start colliding in the Pacific, some admiral typically gets fired and the navy announces a plan of action to the public, which is the right thing to do. It would be nice to know what Apple's plan is.

This is what seems to be happening here as well, this post is definitely not getting up voted, however, there are replies from readers in comments, which means it does get some attention. I don't personally care about my HN karma, so I intend to keep this post, but, these observations make me question the HN algorithm -- can the companies like Apple buy their positive outlook on the "self governed" media?

Apparently, on top of all that, MacOS Update Accidentally Undoes Apple's “root” Bug Patch.

Can you point out the workaround to WSJ posts?

In case of WSJ, the workaround requires not just a subscription, but the paid subscription -- yes, you have to pay $$$$ to read the article. It's very annoying and disrespectful to the community. And it ruins the spirit of the open resources like HN.

I'm not complaining, I'm asking the HN community, what does everyone else think? Perhaps I'm the only one who thinks it's an issue. But what if I'm not the only one? Would it warrant some change in guidelines in this case?

that's exactly right

Any language will do. I'm fairly well versed in any middleware technology -- Rails, Django, Java, node.js. For the presentation, I'd like to stick with Rect.js/ReactNative. So I guess, back to the language question -- combination of JS on the server and the client will do just fine. My goal is to keep it as simple as possible and really focus on what can be done with blockchain.

On another thought, some recruiter do spend time on an introductory call with me, they appear to be studying my background and qualifications and do send few interesting jobs initially, but then, almost always, something horrible happens and they start sending my way every single job they've got. At that point, I just stop responding to these individuals and send their emails straight to spam (hoping it will train the filters correctly, but wondering, how many legit opportunities were missed simply because they got stuck in spam box). I'm hoping recruiters are reading this post and draw conclusions. But that was my original question -- perhaps, they (the recruiters) are doing so great these days, so that they simply do not care.

The app actually does seem like a great idea. I would love to become early beta tester when it's out -- please keep me posted.

In theory, such an attack is possible, in practice -- very unlikely at this point given the number of miners out there. Here is what it was in 2015: http://www.zerohedge.com/news/2015-11-19/bitcoins-computing-... Today it's even higher than ever: https://news.bitcoin.com/why-bitcoin-is-close-to-a-record-br...

How can you ban something that can not be banned by design?

I suppose, just the matter of preference. Personally, the startup option seems to be more appealing to me.

That's what I figured. But there have to be some online resources for this specific purpose. Actually, after performing an initial search -- there seem to be too many of them already. Wondering, which ones really work, and what to avoid.

By the end of day 3, finally, it was reviewed and approved. After all, as it was suggested by some, the weekend does not seem to matter. Still very disappointing that the "expedited" review took 3!!! times longer than the regular one which happened just a day prior.

Day 3 -- still waiting for the "expedited" review to start. My app is still crashing in prod.

Am I the only one who can see the problem here? So far I've gotten the responses that sound like the following: "dude, this is your own fault" or "this is how Apple works, their expedited review is always faster because it's called expedited". In the meanwhile, I'm still waiting, while waiting -- loosing my clients. Perhaps, this is life, and there is nothing that can be done.

I appreciate your advice. But things still fall through cracks. We do have automated tests in place, we have ran manual regression test before and after the release on test devices -- still, the crash happened for 2 most critical clients of ours. Yes, we are going to increase the testing etc, but testing does not solve the problem, it just decreases the chance of the problems to happen. This is not the issue I was trying to bring up here on this thread. The issue is that if the "expedited" review takes significantly longer (perhaps not consistently), is it a red flag for Apple to do something about improving it. If the process was designed to address the critical client's issues -- it currently does not work. I'm loosing my clients and Apple is not there to help. If I only knew what I'm getting into, I would have submitted through regular process, because, as of right now, it takes only a day for review to complete.

Perhaps they should consider removing the "expedited" process altogether to avoid confusion. Or perhaps allow a single request to go in both queues at the same time to see which one wins. I know, it's just me who is having the problem. How do I explain it to my customers who are fleeing my product?

In my case the expedited is already 2!!!! times slower. And it's still not over. The review process has not even started for the "expedited" request. Just a day earlier the normal request was already processed and approved. I really appreciate that Apple has worked hard on shortening the regular queue. Is it time for them to start optimizing the "expedited" process so it does happen quicker than the regular one?

Yes, but that's exactly my point. If current review time is 1 day, should it mean that expedited review currently should be shorter than that?