Runtime 3.4.4 available


I see 3.4.4 is available. Where do I find the documentation on this release to see if its likely to cause me any issues?

AppGyver is not releasing BETA releases publicly ASAIK, so this one is a production one, meaning it is stable and it has some bug fixes probably. I believe that the documentation will be updated shortly so you can see what’s new in this release. :slight_smile:

Thanks. When I see a release made publicly available from anyone in advance of the documentation I know for sure there are plenty of ad-hoc processes in the development loop. If this part of the process is a bit out of order then its logical to assume that its not the only part in this situation.

Fingers crossed the release is better than the process :slight_smile:

Let’s hope there are some reasonable fixes/new features, finally. :slight_smile:

1 Like

It errored when I tried to build IOS

My app errored too and I am not able to build in 3.4.4.

My app still builds fine in runtime 3.3.3.

So much for thorough testing …

It really would not be that difficult to batch run all apps compiled in the past month and ensure that none errored on build. It would be sensible and competent. Let´s see if we can get the boss to offer his thoughts?

@Marko_Lehtimaki - are you able to shed some light on how a new release can make it through QA and simply not work?

A simple solid process would be to check all of the apps in current development and at least check to see they built without error?

@Phil_Evans It would be understandable if it would crash after some huge changes or new features, but in this release (after 5 WEEKS!) there are only 2 bug fixes. This really scares us. Like if an update with only two bug fixes can break the whole build process, what will happen when there will be a major update?

Yes, its concerning. My focus is on encouraging Appgyver to be as good as they can be, now that I´ve invested a load of time.

1 Like

What is concerning is their ideas. For example the new UI designer? That one that basically screwed up half of the apps in AppGyver? Whose idea was it?! And I really hope there are not gonna be another update like this. Let’s hope, they will focus on the 3rd party components instead of as EOD for 3rd party components was Q1/21 :smiley: I understand it is not an easy task, but everyone here roots for them! :slight_smile:

Hey everyone, and thanks for the feedback!

I want to make it very clear, that we’re pushing hard to both get new game changer features such as the third party plugins out for everyone to use, as well as roll out bug fixes, but it’s not a quick and easy task. For example, the third party plugins require many fundamental changes in our underlying infrastructure and the core runtime.

One of the first changes that we had to get implemented was the way we build the apps through the build service. We had to ditch the whole implementation that has been in place for the past 8 years, and create a completely new system. We’ve tested the new version to best of our abilities, but admittedly could have still improved a lot upon on the QA side – build error regressions are not acceptable.

Alongside the changes that are happening with the runtime, we’re also pushing towards a better testing infrastructure, to be able to release new versions quicker, and with better quality - this also includes more robust test automation for the build service.

That said, catching every single issue when we’re testing internally and in a non-productive landscape is unfortunately more difficult than we’d like it to be – some of the issues we’ve faced recently with the builder were only happening in production, under certain conditions. With hindsight, there are of course testing strategies we could’ve gone with to catch these errors beforehand, and we do acknowledge that.

I also agree that we need to be more on top of the changelogs and communication on what has happened. We’re also improving our processes on that front.

That being said, we’re trying to fit in as many bug fixes as we can into given release, while balancing to fit in the more fundamental, feature-enabling changes.



Firstly, thanks for a great, open response.

Does that mean that the test strategy going forward will learn these lessons? For me, the key ones are that documentation proceeds the release and that any app built within say the last month has been tested to see that it compiles without error?

Of course there will be bugs within specific apps that compile ok but have issues running due to something unforeseen, but that´s acceptable I beleive.

An additional issue with 3.4.4.:

Can’t click the ‘Run Test’ button anymore in the data tab of the Composer. The button is required to use ‘Set schema from response’.
Only the data resources with ‘Url-placeholder’ and ‘HTTP header’ are affected. For a data resource with no such input required, it works.

@Kristian_Gerkman : Wouldn’t it be appropriate to roll back to the previous 3.4.3 ? From what I can read in the changelog, the improvements (setting colours; triggering action sheet) seem not to be as critical as the damage, that came with 3.4.4
And with the error stated by @JOHN_WORSHAM already 14 days ago, it looks like there is no manpower available to take care of it.

1 Like

@Phil_Evans I understand the frustration. We’re working on hiring more people to do documentation and improving our testing infrastructure, including our built apps. The situation will get better over time, but of course it’s a pain to wait :disappointed:

@stayfoolish (just for clarity, 3.4.4 is the runtime version, e.g. preview app and standalone built app, but it’s not the same as Composer version. This data tab problem you’re experiencing is happening solely within Composer and not the Preview apps. Composer Pro build number is visible under Community tab)

Thanks for reporting the data tab issue. There is a fix for the “run test” button coming out in Composer version 3536.

In regards to the build issue by @JOHN_WORSHAM, we have released 3.4.5 for Build Service already a while ago – is the build problem still occurring with that?

1 Like

Hi @Mevi,

thank you for clarifying my misunderstanding of what the runtime does and pointing out, that the issue in runtime 3.4.4. (mentioned by @JOHN_WORSHAM) is already taken care of.

Well, it makes me wonder now:

  • does the changelog document the updates of the Composer under the headline ‘platform releases’? If so, the bug I reported yesterday about the deactivated ‘Run Test’ is showing up since the latest release on 2021-12-09? It is hard to imagine that nobody in the community ran into it in the meantime and took the time to report it.
    The documentation doesn’t mention the composer version in the changelog.

  • Until today the release of the runtime version 3.4.5. is not documented in the changelog. Therefor it seemed to me like the issues with 3.4.4. were still existing. I did not observe that issue myself and only read about it in this thread.

1 Like

@Mevi - We still seem to be having issues building for iOS under 3.4.5

Runtime version: 3.4.5; AB version: 0.2.51 COMMAND: npxrnv export -p ios -s standalone_appstore -c standalone --ci --yes --skipRnvCheck --packageManager yarn --template @appgyver/orchestra-template-standalone@3.4.5 --xcodebuildArchiveArgs “OTHER_CODE_SIGN_FLAGS=”–keychain\ AppGyver-379183"" FAILED with ERROR: TypeError: next is not a function at next (/private/var/folders/pf/p5g2vb2j0yx1x6vlmxdppc700000gn/T/379183-ios/node_modules/rnv/src/core/projectManager/buildHooks.js:19:54) │ Project location: │ │ ./platformBuilds/standalone_ios/RNVApp.xcworkspace │

  • 3.4.4 is fine for iOS
  • 3.4.5 is fine for Android now

@stayfoolish You’re right that the changelogs aren’t currently up to date. :disappointed: We’re aware of it and have been working on our processes to improve these in the coming releases, so hopefully you’ll see improvements in the coming weeks.

@Chris_Revell Hmm, I haven’t seen this before, please report it at our bug tracker so we can get it checked out :thinking:

1 Like

@stayfoolish just to let you know, a changelog for Composer release of Friday was added, and some changelogs for what happened between this release and the previously last documented one in December were scraped together. The “run test” problem was now fixed in the release that went out on Friday.