Imagine that you wanted to integrate Nano — the fee-less, instant, and environmentally friendly cryptocurrency, or BANANO — the fee-less, instant, rich in potassium cryptocurrency into your application. Whether it’s an exchange, casino, faucet, game, store, or vending machine— one of the first things you’ll need to do is figure out how to interface with a wallet.

Intimidating right? Luckily if you peruse the Nano Documentation you’ll quickly find out that Nano has a developer wallet built-in, right into the node! It has a full set of APIs that lets you create accounts, send Nano, receive Nano, etc.

But then when you read a little more about it and see that the developer wallet isn’t recommended for production integrations, it’s tightly coupled to a node, and what if you have disk space or bandwidth constraints? Running a full node probably isn’t something that you want to do. The answer to these problems is external key management . But what does that mean? Well, it basically means writing your own wallet, manually crafting and signing blocks, and using any node(s) to publish the block. All while taking proper precautions along the way to make sure blocks are confirmed and avoiding duplicate transactions. Today we’re announcing a new developer wallet that gives you external key management and incredibly high performance right out of the box…

What is “Pippin” Anyway?

To put it simply, Pippin is a Nano (and BANANO) wallet for developers. Pippin is the first wallet of its kind that is 100% compatible with the developer wallet (aka “node wallet”) APIs. Of course the node wallet isn’t recommended for a lot of use cases, but a lot of developers use it anyway — because as you might expect, it’s the easiest solution and it generally works well enough. One of the goals of Pippin is to provide a production-ready, external key management solution that’s incredibly easy to setup and maintain.

Pippin has numerous advantages:

• It’s a drop-in replacement for the node/developer wallet
• It has native support for DPoW and BPoW
• It’s completely detached from the node — meaning, you can use Pippin with any public node (no need to run your own node, you could also run a node in 1 location and have pippin on any number of machines using the same node)
• It’s compatible with multiple database backends (SQLite, MySQL, PostgreSQL)
• It can lazily auto-receive transactions (for example if you don’t want to compute PoW every time your account receives some coins but you also don’t want to explicitly receive them, Pippin can just receive blocks on demand when you need to perform a send — this also works well for when your wallet is locked and cannot auto-receive)
• It supports encrypting seeds and private keys
• Is fully asynchronous and easily scalable thanks to per-account, thread-safe distributed locks.

It’s Also Very, Very Fast

A benchmark was constructed that:

1. Created a new wallet with 21 accounts, and opened one of the accounts with some coins. (1 block)
2. Create 20 transactions to 20 different accounts from the first account. (20 blocks)
3. Receive all 20 transactions across the 20 different accounts (20 blocks)
4. Send all of the coins back to the original account in 20 more transactions (20 blocks)
5. Return coins to sender (1 block)

The same node was used for both Pippin and the node wallet, the same PoW provider was used, and the exact same amount of transactions were made in the exact same way.

This was repeated 3 times for each wallet. Pippin was consistently at least twice as fast as the node wallet.

The Technology Behind Pippin

Pippin is written in Python, it is able to perform incredibly fast by using libraries such as asyncio, uvloop, asyncpg/aiosqlite/aiomysql, rapidjson, and others.

It uses the brilliant nanopy library for signing blocks and generating work, which itself uses C-bindings for ed25519 and blake2b (in the most basic terms, this means that it’s fast).

…but how is it so fast? Pippin uses a brilliant per-account distributed locking mechanism that’s backed by Redis. This means that every account can operate completely independent of one another, while still operating in a synchronous fashion on its own chain. So if you push 500 transactions that belong to account #1, then push a transaction that belongs to account #2 — the account #2 transaction will get processed immediately, even though account #1 has 500 pending requests to handle. This mechanism allows for extremely high concurrency and scalability as you increase the number of accounts, it even is safe across multiple processes.

Additionally, pippin uses a process pool that’s configurable for local work generation, although GPU PoW isn’t natively supported, you can use external work peers, run your own nano-work-server instance, or use a service like BoomPoW.

Start Using Pippin

Pippin is available on PyPi and requires Python 3.6 or newer.

Simply install it with pip

% pip3 install pippin-wallet

Then run the server with the command pippin-server

More comprehensive instructions are outlined in the Pippin README.

Thanks for reading!

Appditto Website: appditto.com

Appditto Twitter: @appditto

Appditto Github: @appditto

Appditto Instagram: @appditto

Introducing Pippin — High Performance, Production-ready External Wallet for Nano and Banano was originally published in Appditto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Flutter is a modern mobile app development framework that lets you develop beautiful, highly performant apps in very little time. At Appditto we already have multiple Flutter applications in production — including open source projects like Natrium, Kalium, and Blaise. The biggest pain point of our development process has been the testing, building, and deploying process for all of our apps.

The old way…without CI/CD or Fastlane

If you’ve ever gotten any mobile application into production you can understand the general process, usually it looks like this:

1. Run tests…and wait
2. Tag the release
3. Build the signed android binary (.aab or .apk) …and wait
4. Login to the Google Play Developer Console and create a new release
5. Upload it to Google Play…and wait
6. Fill in your changelog(s) and other general information and publish your app

In the case of a cross-platform app, we can’t forget about iOS

1. Start any iOS-specific tests…and wait
2. Build the ios app (flutter build iOS)…and wait
3. Archive the app in xcode…and wait
4. Upload the app to the App Store via xcode…and wait
5. And wait for the App Store to process your upload
6. Log in to App Store Connect and create a new release
7. Fill in any changelog(s) and other information and submit it for review

What’s wrong with all of that, you might ask?

Just to name a few…

• The entire process for just 1 app can take more than an hour, just to get it submitted for review.
• If you introduced a change that caused tests to fail, you don’t know about it until you are ready to release an update.
• If you introduced a change that caused the build to fail, you don’t know about it until you try to build it.
• It’s prone to user error. There’s a lot of steps in the process, it can be easy to miss something.

The Solution: Continuous Integration & Continuous Delivery

We identified the need for continuous integration and continuous delivery (referred to as CI/CD) almost immediately, but there’s a lot of competing solutions out there that we wanted to research and try before choosing the one that best fit our needs.

For our Flutter applications we needed to:

• Automate tests for dart code, Android code, and iOS code
• Automate building the iOS and Android applications
• Automate deployments to the iOS App Store and the Google Play Store

Fastlane is the first part of our continuous integration solution, it is a powerful tool that allows you to automate iOS and Android builds, as well as automate deployments to both of the app stores. It also has several other benefits such as allowing us to manage store information, changelogs, and more in our repository.

In this guide, we’ll walk through the steps required to integrate GitLab CI/CD and Fastlane into your project.

Before we get started…

This article makes a few assumptions you should be aware of.

• Everything described is applicable to Unix environments only — such as MacOS or Linux. If you are using Windows, using the WSL is required.
• MacOS is required to build and sign iOS apps. You can skip the iOS sections if you are only planning to build for Android or don’t have access to a Mac.
• You need to have an Apple Developer Account to publish iOS apps to the App Store
• You need to have a Google Play Developer Account to publish Android apps to the Play Store.
• App Store Privileges — It’s very important for CI that we add a second account to App Store Connect without 2FA-enabled. You can give it the “App Manager” permission and a secure password. If you aren’t sure how to add an additional user, here’s a guide. Anywhere you are asked for credentials for the app store, you will need to use this account.
• Git Usage— It’s assumed that you are using Git for source control. It doesn’t matter if your repository is self-hosted, on GitHub, on Bitbucket, on GitLab, etc.

This guide will assume that you want to automate tests, builds, and deployments to both of the app stores — which means that all of the above is required to completely follow this guide.

Getting started with Fastlane and Flutter

We need to get Fastlane installed and configured for our project. The first step is to install fastlane, it can be installed with gem.

# gem install fastlane

Next navigate to the root of your Flutter project, where you need to initialize fastlane for both android and iOS.

# cd path_to_my_awesome_flutter_app

First, you might want to add the following lines to .gitignore.

# You definitely want these
**/ios/*.ipa
**/ios/*.app.dSYM.zip

# These are optional
# For our open source projects we choose to exclude some metadata that contains private information
android/fastlane/report.xml
ios/fastlane/report.xml
ios/fastlane/Preview.html
ios/fastlane/metadata/review_information
ios/fastlane/metadata/trade_representative_contact_information

Fastlane install for Android builds and deployments:

You need to obtain a json file that contains an access key from the Google Play Console. More details available in the fastlane docs.

We recommend that you keep this file outside of your repository and in your home directory /home/<YOUR USER>/keys/android/myaccesskey.json or /Users/<YOUR USER>/keys/android/myaccesskey.json (for MacOS). When prompted by fastlane use the path ~/keys/android/myaccesskey.json as the location where you stored your key.

# cd android
# fastlane init
# cd ..

Follow the prompts and make sure all of the information is correct, fastlane will create several files in your project once you are finished.

Fastlane install for iOS builds and deployments:

As mentioned in the pre-requisites, you want a dedicated account without 2FA to use for continuous integration. For iOS, the fastlane installation is similar but you’ll need to use the apple ID and password of your developer account without 2FA.

# cd ios
# fastlane init
# echo 'gem "cocoapods"' >> Gemfile
# cd ..

Follow through the prompts and make sure the detected information is correct. Managing metadata is up to you, it means you can manage changelogs, descriptions, icons, and other data from within your project. In our case, we chose yes for those (with the exception of ios review_information and iOS trade representative contact information — simply delete the metadata you don’t want to manage via fastlane, and add it to .gitignore).

You can check in and push all of the files fastlane has created in your project.

A word on code signing…Android

This article assumes you have setup code signing for your android app as described in the flutter documentation. That means a .jks key store, with a key.properties file excluded from source control that has the password, keyAlias, etc.

If you haven’t configured code signing yet, then follow the steps outlined here before continuing with this guide.

A word on code signing…iOS

For iOS, the story is a bit more complicated.

We’re going to use Fastlane Match, to manage the certificates required for code signing on iOS. Here’s how to do it.

1. Create a private git repository named ios-certificates.git or similar
2. Run the following

# cd ios
# fastlane match init
# fastlane match
# cd ..

Follow the prompts to setup match, once completed it will create ios/fastlane/Matchfile, which contains information about the ios-certificates repository.

Configuring Fastlane for Flutter and GitLab (Android)

We installed fastlane with fastlane init, and it configured itself for an Android project. The problem is, fastlane configured itself for an Android project — not for a Flutter project.

The main fastlane configuration can be found in android/fastlane/Fastfile, it has some default lanes. You can think of a lane as a group of tasks. The Fastfile is written in Ruby, so you can write any ruby code within it.

We want two new lanes for android, build_android and deploy_android. The first builds and signs our Android app, the second uploads it to the play store.

We’re going to make some simple shell scripts to build the app and run tests, to keep our Fastfile clean.

# touch android/fastlane/flutter_build.sh
# touch android/fastlane/flutter_test.sh
# chmod a+x android/fastlane/flutter_build.sh
# chmod a+x android/fastlane/flutter_test.sh

These create two empty scripts and make them executable (You can skip flutter_test.sh all together if you are planning to add GitLab as it will become redundant in our pipeline)

Contents of flutter_build.sh:

Contents of flutter_test.sh:

Now we can create our lanes in android/fastlane/Fastfile

Breaking down the first lane, build_android:

• sh "./flutter_test.sh" : Executes our tests, you may choose to remove this especially when using GitLab CI as we’ll do tests earlier in our pipeline.
• sh "./flutter_build.sh" --clean : This builds our .aab (Android App Bundle), this is the binary we want to use when uploading to the play store.
• sh "./flutter_build.sh" --apk : This builds our standard fat .apk, it’s also completely optional but we like to have it in our archive as it’s easier to install if you want to downgrade to a specific version, offer a download in alternative places, etc.

Our second lane, deploy_android, is where things get interesting.

In this lane we are uploading our build to the play store using the fastlane function upload_to_play_store. This single lane allows us to upload to production, beta, alpha, or internal tracks — pretty neat!

You can use these lanes as demonstrated below:

Build the release binaries:
# bundle exec fastlane build_android
Production deploy:
# bundle exec fastlane deploy_android production:true
Beta deploy:
# bundle exec fastlane deploy_android beta:true
Alpha deploy:
# bundle exec fastlane deploy_android alpha:true
Internal track deploy:
# bundle exec fastlane deploy_android internal:true

And we’re done! Fastlane can now build and deploy our Flutter application. We’ll automate this process later, but first we need to configure our iOS build.

Configuring Fastlane for Flutter and GitLab (iOS):

Note: A MacOS machine with the latest XCode installed is needed for this section

Building for iOS and deploying to the App Store is a bit more problematic, mainly because there’s more steps involved. Luckily we can still simplify the process with Fastlane.

We want to start with creating the same two scripts we made for Android

# touch ios/fastlane/flutter_build.sh
# touch ios/fastlane/flutter_test.sh
# chmod a+x ios/fastlane/flutter_build.sh
# chmod a+x ios/fastlane/flutter_test.sh

The contents of flutter_build.sh:

--no-codesign is used in our flutter build step because unlike android, flutter build doesn’t give us a binary that can be uploaded straight to the AppStore. There’ll be an additional build step later which will be where we sign our app.

And flutter_test.sh:

Now we need to create our lanes, like how we did on Android.

Like android, we also want a build_ios that builds and signs our app, as well as a deploy_ios that uploads our app to the app store.

Here’s the whole file, we’ll walk through what it means later:

The Fastfile is Ruby syntax, so when we define variables and functions it’s written in Ruby.

The first group of functions and variables are for creating a temporary keychain which will be used to store our signing and deploy keys.

First we set a couple of variables with the temporary keychain name and password. These are “default” values because we also have the option to include a more secure password from the environment, which we’ll see later.

Then we have a few ruby functions which create and delete our temporary keychain.

• delete_temp_keychain will delete the temporary keychain if it exists
• create_temp_keychain will create the temporary keychain with a name and password
• ensure_temp_keychain simply deletes any existing keychain of the same name, and creates a new one with the given name and password.

Why use a temporary keychain?

It’s not required to create a new keychain every time you build the app with Fastlane — the default Login keychain, or any other keychain on your system is perfectly fine. There’s a couple reasons we prefer this method over using the login keychain.

1. You don’t need to expose your login password. If you use your login keychain with Fastlane, it will prompt you for a password to unlock it when you run match — not really a problem on a development machine, but for CI/CD we don’t want to be prompted for a password. So we can either provide our login password in the environment or use a different keychain — which is what we’re doing here.
2. You can provide a strong, random password every time when the process is automated via GitLab — which we’ll see later. This ties into increased security.

Then we have our two lanes, similar to android. One is the build step and one is the upload step.

Breaking down the build_ios lane

• It disables “Automatic code signing” which is what we want for our CI/CD server. The disable_code_signing method actually changes your .xcodeprojfile, if you run this locally you probably don’t want to check the modified file into git. You could backup the original at the beginning of the lane if desired, and restore it later by doing something like cp Runner.xcodeproj Runner.xcodeproj.bak.
• It creates our temporary keychain with a name and password from the environment, otherwise uses the default one.
• It runs fastlane match, to install the certificates and profiles into the temporary keychain
• It runs the flutter tests and build
• It builds the .ipa file and signs it, which is what we need to upload to the App Store
• It deletes our temporary keychain at the end

And the deploy_ios lane is where things get really cool

• It can upload to test flight
• It can upload to the App Store and submit it for review automatically! It will upload, make sure everything is valid, wait for processing, then submit it for review all in one step.

Like android you can do either or with parameters

# cd ios
To upload to testflight:
# bundle exec fastlane deploy_ios testflight:true
To submit for review:
# bundle exec fastlane deploy_ios

One more thing

For iOS apps, if we want to automatically submit them for review we need to set the answers for our compliance questions. You can add the following to ios/fastlane/Deliverfile, but change the answers as they apply to your app.

And we’re done with Fastlane!

You can now build and deploy your iOS and Android apps in a couple simple steps.

Automating all of it with GitLab CI/CD

Now that we can build and deploy our apps with a few simple commands, it’s time to automate it. This is where continuous integration comes in.

Why GitLab?

There’s plenty of continuous integration/continuous delivery (CI/CD) solutions out there including Travis CI, GitHub Actions, Codemagic, Bitbucket pipelines, Circle CI, Jenkins, etc. I encourage you to research all of them and determine which one fits your needs the best. For us, we determined that GitLab’s CI/CD would work best for us. That definitely won’t be the case for every team or every project, but here’s the reasons we chose it over the others:

• Ability to use your own runner. Think of a runner like a “worker” — it executes your pipelines and in our case will be responsible for running tests, building the apps, and uploading the apps. Many of the services mentioned only allow you to use their shared servers with limited usage caps. Many offer enterprise solutions, paid plans, and various other things to fit your needs — so again, definitely research them and find what works best for you.
• MacOS Requirement. Flutter applications need MacOS to build the iOS binary and upload to the App Store. If you don’t intend to server iOS users, then this doesn’t apply to you. Most of the services above provide MacOS servers that you can use (GitLab happens to not provide these), but they’re generally more expensive and more restrictive. Also, we’re dealing with very sensitive data — signing and deploy keys, app store manager passwords, google play upload keys, etc. Unless you’re using an enterprise solution offered by one of the above mentioned CIs, this may not be something your internal audit requirements allow for.
• Intuitive Configuration. The yaml configuration that GitLab uses is very straightforward, easy to understand, and easy to work with. You can build very complex pipelines in very little time.
• Intuitive Interface. The experience using GitLab is generally good. It has an interface where you can easily visualize and manage your pipelines, alerts, auto-cancel features, archiving, and a lot more that really fits our needs.

If your project isn’t already in GitLab, you can create a new one, import one, or mirror it from another repository. We chose to mirror it because our projects are hosted on GitHub, but your needs may vary. More information can be found on the GitLab website about creating, importing, or mirroring a project.

What about the server?

As I said above, GitLab does not provide any shared MacOS runners — which we need to build and deploy our iOS apps. Luckily the gitlab-runner software is incredibly easy to setup, you can run it on any MacOS machine including a MacBook.

We chose to setup a bare-metal dedicated MacOS server, this has some downsides — primarily that we need to manage the infrastructure ourselves, keep flutter up to date ourselves, keep XCode and the Android SDK up to date ourselves, etc. However we need MacOS, which is why we chose the bare-metal option instead of using docker containers or a similar lower-maintenance solution. If you want to follow the same approach — a Mac Mini makes a great option and used, older ones are relatively inexpensive. You can also use a hosting provider such as MacStadium or MacInCloud. Or like I said, if you already have a MacOS development box you can simply setup the gitlab-runner on that.

Server Configuration

Note: If you are intending to use the gitlab-runner on a MacOS development machine that has already been configured for flutter development and FastLane, you can skip these steps. If you are intending to build for android-only, you can skip installing XCode.

If you’re using a bare-metal MacOS server you need to install the required software to build iOS and Android apps.

1. Install the Android SDK — Android Studio is the easiest way to install it.
2. Install XCode — via the MacOS App Store
3. Install Flutter — Make sure you also add it to your PATH, as described in the document.

Once these are complete, run flutter doctor -v to ensure everything is configured correctly.

One other thing we’ll want to do, is install XCode command line tools. This can be done by running the following command:

# xcode-select --install

We need to add some environment variables, we can add them to ~/.zprofile (on MacOS Catalina) or ~/.profile (other MacOS versions)

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
# Ruby
export GEM_HOME=~/.gems
export PATH=$PATH:~/.gems/bin

You can also choose to store sensitive variables here, such as FASTLANE_PASSWORD (the password of the AppStore/Developer account you used to setup fastlane with) and MATCH_PASSWORD (the password required to decrypt your iOS certificates.

export MATCH_PASSWORD=abc123
export FASTLANE_PASSWORD=123abc

You can also choose to store variables in the GitLab interface per-project, which is what we’ll do for the rest of the guide. Just know that you have the option to do it this way.

Getting access to ios-certificates

For fastlane match, you should have created a private git repository with all of your encrypted signing/deploy certificates. We need to give this machine access to these.

# ssh-keygen -t rsa

Once complete, you can add read-only access to your repository using your public key (by default located in ~/.ssh/id_rsa.pub). GitHub calls them Deploy Keys.

Installing keys for Android/Google Play

We need to install our jks key store and .json file that we generated earlier. Upload it to your server and copy it to your home directory. For our example we’ll have them at /Users/<YOUR USER>/keys/android/appditto.jks and /Users/<YOUR USER>/keys/android/myaccesskey.json

# mkdir -p /Users/<YOUR USER>/keys/android
# mv myaccesskey.json ~/keys/android
# mv appditto.jks ~/keys/android

Installing the GitLab Runner

We need to install the gitlab-runner software, it’s very easy to do.

In GitLab, navigate to your project settings -> CI/CD -> Runners and find your registration token. It should look like this

It just so happens that ours is YourRegistrationToken, we’ll need it when we setup the gitlab-runner.

To install the runner:

# sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
# sudo chmod +x /usr/local/bin/gitlab-runner

Now that it’s installed, we can register it for our project using gitlab-runner register.

• Choose https://gitlab.com/ when prompted for gitlab-ci coordinator URL
• Enter your token from above, ours is YourRegistrationToken
• Choose whatever description you want
• Choose whatever tag you want, but remember what you chose appditto_mac in our case, will be used to target this specific runner when we create our pipeline.
• For runner type, choose shell

Then all we do is install and start the runner, and it should run as a Launchd service that will start itself upon system reboots, etc.

# gitlab-runner install
# gitlab-runner start

You can refresh the gitlab settings page and you should see your runner appear.

Creating our Pipeline

We saw how easy it was to install the gitlab-runner software and configure out server. Now we need to get into the fun stuff — creating our pipeline!

A pipeline is basically just a set of jobs that may execute in a specific order. For example test -> build -> deploy. The pipeline is triggered on every commit (by default).

We’re going to design a relatively simple pipeline that can test, build, and deploy our app.

We’re going to create a file called .gitlab-ci.yml in the root of our project (awesome_appditto_app/.gitlab-ci.yml)

First part will be the stages, this defines all of the stages in our pipeline.

• test — will be where we run our tests
• update — This is simply going to update our flutter dependencies, we want to run flutter packages upgrade every time because by default GitLab will “cache” the repository instead of cloning it every time (for speed), which means we aren’t guaranteed to have the latest versions of everything unless we do this.
• build — This stage will build our android and iOS app.
• deploy — This stage will deploy our android and iOS app.

Every stage depends on the previous one. So if test fails then none of the other jobs will run, and the entire pipeline will be considered as failed.

—

First we can define a job in the test stage

The job is named tests, it only runs when commits are pushed to the master branch, it is part of the test stage, it only will run on a runner with the appditto_mac tag, it executes one command flutter test and it is interruptible which means it can be cancelled automatically. If there are two pushes on the master branch, GitLab will cancel redundant pipeline runs automatically for us.

—

Then define a job in the update stage

Very similar to the test job, except we’re running two commands instead of only 1: flutter packages get and flutter packages upgrade.

—

Then we can define our build stage. This one consists of two jobs and gets a bit more interesting.

We have two jobs android:build and ios:build.

They are both just a series of shell commands like the previous jobs, although a bit more complicated. The android:build job is creating a key.properties and local.properties file on the fly, which is used by our android build to determine the SDK location as well as access the key store so it knows what to use for signing our app. We’ll get to defining our environment variables later, if you’re wondering what $ANDROID_KEY_STORE_PASSWORD and the others mean and how to define them.

ios:build is creating some environment variables, TEMP_KEYCHAIN_NAME and TEMP_KEYCHAIN_PASSWORD. Remember how earlier we configured fastlane to create a temporary keychain for signing the app? This is just generating a random name and password for that key store on the fly.

Another new thing in this job is artifacts. We want to specify our build artifacts so GitLab can archive them for us. This includes our signed .apk, .aab, and .ipa files. After every successful build stage GitLab will archive the build artifacts so we can come back and download them later, if desired.

—

We can then create some jobs for the deploy stage. We’ll create 4 total. One for production on Play Store (Android), one for App Store (iOS), one for Play Store internal track (Android), one for TestFlight (iOS)

There’s 4 jobs that are part of the deploy stage, you can see that they simply execute some of the fastlane lanes that we created earlier with various options.

The main difference with these is when: manual. We don’t want these deploy jobs to be triggered automatically, because we don’t want to push builds to the AppStore/Play Store every time a new commit is pushed. So with this option, these jobs can be triggered manually after the build stage is complete.

Here’s the entire gitlab-ci.yml that we put together, for reference.

You can do a lot more things with your pipeline. For example, with our open source app we also want to automate release tagging and upload APKs to GitHub, you can see that here for reference.

Check the file in and push it to your repository. You should the job trigger immediately.

Setting up environment variables

Your android build probably failed if you’ve been following this guide. We had specified some environment variables in our .gitlab-ci.yml but didn’t define them anywhere.

We need to define the following:

• FLUTTER_PATH — This is the location you installed flutter on the server (example: /Users/<YOUR USER>/flutter)
• ANDROID_SDK_PATH — This is the location the android SDK was installed on the server (example: /Users/<YOUR USER>/Library/Android/sdk)
• ANDROID_KEY_STORE_PASSWORD — This is the storePassword value in our key.properties, AKA the password used to unlock your key store.
• ANDROID_KEY_ALIAS — This is the name of the key used to sign your app, keyAlias in the key.properties file.
• ANDROID_KEY_PASSWORD — This is the password for the key, keyPassword in the key.properties file.
• ANDROID_KEYSTORE_PATH — This is the location of the .jks file. (example: /Users/<YOUR USER>/android/keys/appditto.jks)

There’s two options for defining these variables that we’re going to cover.

1. Placing them in ~/.zprofile (Catalina and newer) or ~/.profile (Mojave and older).
2. Setting them up in the GitLab interface.

We already briefly covered #1, we’re going to choose #2 this time. There’s pros and cons to each approach but ultimately it’ll be up to you to decide.

Adding them in GitLab is very simple, just navigate to your project settings as seen below and add them:

And we can re-run our pipeline and can see that it passed!

We can see that our deploy jobs did not get triggered, which is what we wanted. When we want to deploy it to the app store we can just login to GitLab and manually run whichever deployment we want.

Let’s Recap

We’ve successfully automated our workflow using GitLab CI/CD and Fastlane.

• On every commit to master, all of our tests and both builds will run
• On successful builds, GitLab will archive the binaries so they are available for us to download later if needed.
• Also on successful builds, our binaries will be available for us to deploy at our leisure with the press of a button.
• If our tests or builds are failing, GitLab will alert us of the failure based on our preferences (email is the default)

Now our code is continuously tested, built, and the latest builds are ready to deploy!

Thanks for reading!

Appditto Website: appditto.com

Appditto Twitter: @appditto

Appditto Github: @appditto

Appditto Instagram: @appditto

Automate Your Flutter Workflow Using GitLab CI/CD and Fastlane was originally published in Appditto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Natrium has come a long way since its inception more than a year ago — it quickly became the most preferred mobile wallet for NANO users around the world. Our own definition of Natrium is Fast, Robust, & Secure NANO Wallet. We take all three of those principles very seriously with Natrium and, thanks to the Nano Foundation, we were able to take security to the next level.

Natrium Security Audit

The Nano Foundation connected us with Red4Sec — an experienced, trusted security firm that has a lot of experience auditing and reviewing cryptocurrency projects, blockchains, and more. Red4Sec conducted a comprehensive security audit and they found that Natrium had no critical vulnerabilities. They had some recommendations to prevent lower risk vulnerabilities that require a higher skill, depend on certain factors — such as being rooted, or are related to protecting less sensitive information such as your public NANO address. Their recommendations have been implemented into Natrium v2.1.

Among these include an option to encrypt your seed with a user-provided password. While Natrium currently utilizes the built-in security of the device itself — using the iOS KeyChain and the Android KeyStore. Users can now add an additional layer of security to their wallet by encrypting their seed with a password that is not stored on the device. This is optional, but it may be beneficial for users who just want to take extra precautions, are using Natrium on a rooted or jailbroken device, or are using Natrium on a device that is not secured by a passcode, pin, or biometrics.

Some of the other changes related to the audit are less apparent, but they include: a warning when users are using a rooted or jailbroken device, cleaning up information leakage in application logs — for example Natrium logging your public nano_ address in general system logs, using a secure clipboard on iOS — disabling Universal Clipboard and setting an expiration for copying sensitive data.

We’re thankful to the Nano Foundation for providing us with the opportunity to be audited, and we’re proud that when people install Natrium they can be confident that their seed, private keys, and other sensitive data is secure.

What Else is New in Natrium 2.1?

In addition to the audit-related changes mentioned above, Natrium 2.1 also adds the following new features:

• Live Support — Chat with us in real-time from within the application. We saw a need to provide better support — people have questions, issues and they aren’t always sure where they should go. Now, they can reach us directly from within Natrium and get answers quickly. We hope that this can make the experience of using a non-custodial wallet, such as Natrium, less intimidating and easier for all users.

• QR Scanner Shortcut — Often times users are sending NANO using QR codes. While this has always been supported in Natrium, now it can be done slightly quicker simply by swiping up on the send button.

• Hide Your Balance — A community requested feature was to be able to hide your balance. If you’re recording a video or making a NANO purchase in public and don’t want onlookers to know how much NANO you own, then all you need to do is tap your balance and it will disappear.

• A New Language — We’ve improved translations for many existing languages, we were also able to add Japanese as a new language, making Natrium even more accessible.
• Face Unlock/Authentication on Android — The Google Pixel 4 was recently announced, it is the first Android device with secure face authentication. We’ve added support for this into Natrium 2.1.

As always, there’s plenty of minor bug fixes and performance improvements — the full progress can be seen on the Natrium GitHub.

What’s Next for Natrium?

We’ve learned a lot since Natrium was initially unveiled over a year ago. Not just in terms of our skillsets, but also about how people commonly interact with Natrium and cryptocurrency wallets in general. We’ve also learned a lot of new things about Flutter, and Flutter has evolved since we’ve initially developed Natrium. We have developed a comprehensive plan to rebuild Natrium using all of the new knowledge we have acquired in the codebase and also in the interface. There’s a lot of things we know we can do better, so we’re going to.

In comes Natrium 3, a light re-design and comprehensive rewrite of a large part of Natrium’s code base. Natrium 3 is combination of all of the things we have learned to date — about how people interact with the app and also simply things we can do better in the codebase. Natrium 3 is our next milestone — we want to make Natrium leaner, faster, more efficient, and easier-to-use than ever before. We’re excited to share our progress on Natrium 3 with you in the coming weeks.

Support Natrium Development

Natrium is open source and released under the MIT license — it is completely free. If you would like to support the development of Natrium, you can donate using the link below:

natrium.io/donate

For more info & regular updates:

Natrium Twitter: @NatriumIO

Natrium Website: Natrium.io

Appditto Twitter: @Appditto

Appditto Website: Appditto.com

Appditto Github: @Appditto

Natrium v2.1 — Security Audit & More was originally published in Appditto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blaise is a next-generation wallet for the PascalCoin cryptocurrency. PascalCoin is infinitely scalable, decentralized, and offers many advanced features. PascalCoin is capable of zero-fee, instant transactions, storing data on-chain, smart contracts, and more. Blaise is now available on the Google Play Store and the iOS App Store!

Blaise 1.0 is Now Available!

After a month of beta testing and new developments, Blaise is now available on the Google Play Store and the iOS App Store!

PascalCoin & Unique Challenges

PascalCoin is an infinitely scalable cryptocurrency with a lot of innovative features including zero-fee transactions, on-chain unique account names, a community-driven governance structure, and much more.

PascalCoin’s unique design comes with some unique challenges that many consider a barrier for adoption, including:

1. Obtaining an Account— Accounts are “mined” and stored on-chain, they cannot simply be generated through a key derivation function like most other cryptocurrencies. This has numerous benefits including: simple, easy-to-remember account numbers instead of long, complex hex-strings, reducing the “squatting” on account names (as they are stored on-chain), and the ability to trade, sell them (e.g. for vanity purposes, or to sell a name). Unfortunately, the process of getting an account has been confusing and difficult for many users.
2. PascalCoin had a lack of wallet options, particularly light wallets. The community wanted an intuitive wallet that would be incredibly quick to setup and use, while still supporting PascalCoin’s numerous and innovative features.

Meet Blaise

Blaise was developed for PascalCoin by Appditto as a part of PIP (PascalCoin Improvement Proposal) #35C. Solving these unique challenges were fundamental goals of the Blaise project — and we’ve succeeded. Blaise solves both of these challenges — it’s innovative, unique, and easy to use. The account process has never been easier.

Getting an Account, Made Simple

Blaise introduces an innovative “borrow an account” system. After just a couple of taps, you‘ll be given a “borrowed account.” Simply send some Pascal to it and the account will be permanently transferred to your public key. The only cost is a small 0.25 pascal fee (less than $0.04, equivalent), that will be deducted automatically from the funds you send. The account, once transferred, is yours permanently.

Send Pascal, However You Want

Sending Pascal is easier and faster than ever with Blaise. Converting to local currency, scanning a QR code, adding payloads, sending to an on-chain account name, a feature-rich address book. All of these options are bundled into a streamlined, innovative interface.

Blaise Speaks Multiple Languages

The entire interface, made to speak your language. Choosing your native language or preferred local currency couldn’t be any easier.

The Many Faces of Blaise

Blaise has multiple looks that have been meticulously crafted down to the finest details — including animations, illustrations, and even the app icon itself.

Receiving Pascal

Ding! Blaise will alert you when you receive Pascal to any of your accounts through a push notification. Tired of constantly checking your wallet to see if that exchange withdraw has finally been processed? With Blaise, there’s no guesswork and you’ll know exactly when funds hit your account.

The Technology Behind the Blaise Wallet

We developed Blaise Wallet using the latest in mobile application frameworks, Flutter. Flutter applications are developed using the Dart programming language.

There’s three primary components that drive the Blaise Wallet:

1. PascalDart — A 100% dart PascalCoin library, it supports key generation, ecliptic curve cryptography — including ECDH signatures and ECIES encryption, a full JSON-RPC API for interacting with the PascalCoin node, and many other features that are critical to the operation of Blaise.
2. Blaise Flutter Application — The user-facing application. It includes everything the users see and interact with, it also is responsible for critical functions such as secure key storage. The business logic lives here.
3. Blaise Server — The server that powers Blaise. It is written in Python — using asyncio and AIOHTTP for incredibly high performance and high concurrency. It powers the major “borrow account” feature, it provides a web-socket service so it can push price updates and new transactions to users, it is responsible for sending push notifications using Firebase Cloud Messaging, it also enhances server security by restricting access to the PascalCoin node.

All of these are open source and released under the permissive MIT License.

Get Blaise!

Blaise is completely free and compatible with most Android and iOS devices.

Get it for Android on the Google Play Store!

Get it for iOS on the App Store!

Visit the Blaise Website!

Users who do not have the Google Play Store available in their region or on their device can get the latest releases from GitHub.

Thanks for reading!

Appditto Website: appditto.com

Appditto Twitter: @appditto

Appditto Github: @appditto

Appditto Instagram: @appditto

Meet Blaise — Simple, Sleek, & Secure Pascal Wallet now available on the iOS App Store and Google… was originally published in Appditto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blaise is a next-generation wallet for the Pascal cryptocurrency. Pascal is infinitely scalable, decentralized, and offers many advanced features. Pascal is capable of zero-fee, instant transactions, storing data on-chain, smart contracts, and more.

What is Blaise?

Blaise is an all-new wallet developed with Google’s Flutter framework. It is being developed as part of the Pascal Improvement Proposal (PIP) #31. The goal has been to create an intuitive, secure wallet that supports both the essential and advanced features the Pascal blockchain is capable of.

The Technology Behind the Blaise Wallet

We developed Blaise Wallet using the latest in mobile application frameworks, Flutter. Flutter applications are developed using the Dart programming language.

The first technological hurdle was to develop an offline-signing library that would allow the app to sign and create operations completely on the device itself, this results in private keys never being sent to the server. The library we developed is called pascaldart — it implements signing, encryption including ecies encryption for payloads, JSON-RPC, and more. It is available publicly here and is also on Github.

Another major consideration when dealing with private-key security is storage of the private key. The private key needs to be stored securely on the user’s device — we use the native Android KeyStore, and the iOS KeyChain for secure key storage.

For the application state we are using mobx. This is a reactive state management system that efficiently maintains the entire state of the application and all of the user’s accounts.

User Interface & Experience

Pascal has a feature rich protocol with a lot of different capabilities. We tried to highlight these features without overwhelming new users. We created a simple & friendly interface that can suit both new users and enthusiasts alike. We made various custom animations and illustrations to create an easily understandable and enjoyable experience for everyone.

We also developed various different features that would make operation of the wallet faster while feeling familiar to users with different levels of knowledge about the Pascal protocol, such as the contacts feature.

At Appditto we pride ourselves on using the latest, most innovative technologies in order to provide not only the best product possible — but also the best user experience. Today we’re ready to share Blaise with the public — Blaise is now available for open beta testing on iOS TestFlight and on the Google Play Store for Android users.

How do I try Blaise?

Anyone can sign up for the beta as long as they have an iPhone with iOS 10 or newer or an Android device with Android 4.4 or newer.

Android Users — Sign up by clicking here!

iOS Users — Sign up by clicking here!

What’s Next?

There’s a lot of work to be done still — including translations, currency conversions, easy account acquisition, and a web-socket service that will push new transactions as well as allow for push notifications.

Pascal accounts are acquired by mining, unlike traditional cryptocurrencies. Users need to acquire one before they can interact with the Pascal network. Our primary focus is streamlining this experience and making it as easy for users as possible.

We’ll be pushing updates in the coming weeks introducing these new features and improvements, you can follow our progress on the Pascal Discord, in the channel #pip-0031c.

Thanks for reading!

Appditto Website: appditto.com

Appditto Twitter: @appditto

Appditto Github: @appditto

Appditto Instagram: @appditto

Meet Blaise: Simple, Sleek & Secure PascalCoin Wallet — Public Beta now Available for iOS and… was originally published in Appditto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Natrium is a Next-Generation App for a Next-Generation Cryptocurrency

Natrium is a wallet built for NANO that is built using the fast, native cross-platform framework — Flutter. Natrium is fast and it’s full of features: Paper wallet / seed sweeping, push notifications, multiple accounts, contacts, numerous currency conversions and translations, and more.

Representatives & Decentralization

Decentralization is a key component to making NANO network stronger. Because of this, we started focusing on the things that can speed up this process and make it easier. Today we have the first result of our efforts: We are adding a pre-populated list of representatives that have a relatively small voting-weight — provided by My Nano Ninja. This makes choosing a quality representative incredibly easy — just tap “Pick From a List” button and pick a representative, no need to go search for a representative and copy paste the address. But if you want to do that, you still can with the “Manual Entry” button.

Nano Prefix

Existing Android users using Natrium are already familiar with this. Their address begins with nano_ instead of xrb_. For iOS users, we reverted to using xrb_ due to lack of support with some other services in the Nano ecosystem. However, with the news about the upcoming Nano V19 emitting nano_ prefixes — Natrium is now using nano_ everywhere. You can still send to either type of prefix, but throughout the app addresses will be represented with nano_. For some parts such as account history, it will still display with xrb_ until we upgrade our node to V19. After that, app-wide everything will be using the new prefix.

Natrium, Everywhere

When we started, our short term plan was to create a fast, innovative mobile wallet that runs both on iOS & Android natively, from a single code base. Today, we have officially achieved that. This means every update we release from now on, will come to both iOS & Android at the same time.

But that’s not all, we want our users to have the same great experience everywhere. Mobile, desktop and web. We’re closely following the development of Flutter, and once the tech is there - like we did with Android & iOS — we’ll make sure to be the first ones to implement it.

More Than a Wallet

As you may now, we have been focused strictly on creating a solid wallet for Nano that everyone would enjoy using everyday, from the most avid Nano enthusiast to someone that just met with Nano.

Today, we are proud to announce that we are rebranding. Instead of “Natrium Wallet”, the new preferred name is simply “Natrium”. We‘re working on other Nano-related products, many of which will be a vital part of the Natrium app. All these developments will be a part of the Natrium brand — interested in what we’re doing? Follow us on twitter.

For more info & regular updates:

Natrium Twitter: @NatriumIO

Natrium Website: natrium.io

Appditto Twitter: @appditto

Appditto Website: appditto.com

Appditto Github: @appditto

Natrium’s Next Big Update Released on Android and iOS was originally published in Appditto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Natrium — a mobile wallet for the NANO currency — is now available on the iOS App Store!

Natrium is an intuitive, user-friendly mobile wallet for the NANO cryptocurrency. Natrium 1.0 was originally released in November on Android and the reaction to the release was overwhelmingly positive. Since then, we’ve been investing hundreds of hours on the next generation of Natrium.

Natrium 2.0 was rewritten from the ground up using Flutter, a cross-platform framework that allows Android and iOS apps to share the same codebase while also providing native-performance.

We’ve added many new features since Natrium’s initial release — most notably the ability to redeem paper wallets instantly. We’re excited to announce some big new features that are available today.

Multi-accounts, Made Simple

Probably the most requested feature of our users has been the ability to manage multiple accounts from within Natrium. The biggest challenge we had to overcome when considering this was, how can we accomplish this without cluttering the interface and obstructing the current flow of the interface?

Today as part of this release, multiple accounts are now supported in Natrium!

We expanded the interface to allow for multiple accounts by using an account-switching interface that most people are already familiar with — similar to some of the most popular apps people use such as Twitter, eBay, Telegram, and many more. You can add up to 20 accounts, hide them, and rename them. Switching to a different account takes only one tap, then you’re instantly ready to use it. Push notifications work for all 20 accounts, tapping a notification will open the app and automatically switch to the account the notification is for — making the entire experience as seamless as ever.

System-wide Themes

Natrium 2.0 introduces a comprehensive theme system. From clean and professional to wacky and bright, there’s a style for everyone. These themes customize the entire experience — even down to the app icon itself.

We plan to add more themes over time, and are considering implementing the concept of un-lockable themes. For example, change your representative to a highly rated-one from My Nano Ninja — then unlock a new theme. This is just one of the possible ways that we can expand the themes in the future to make the experience more interactive and more fun.

Near Instant Notifications

One of Natrium’s most unique features, push notifications, isn’t all that new but it has gotten even better since we upgraded our backend to the new Nano v18 Dolphin release. We’ve seen notifications arrive in less than a second after the NANO has been sent. This is an incredible step forward for NANO and the future of cryptocurrency payments.

Other Features

Full list/documentation at Github:

• Send/Receive NANO securely
• View your entire transaction history
• View transaction details using NanoCrawler
• Share a personalized card with your QR code and address as a PNG image
• Manage multiple accounts on a seed
• Fully featured contacts/address book
• Change your representative
• Biometric authentication (FaceID+TouchID)
• QR scanning
• Deep link/URI support)
• Paper wallet loader/Seed sweeper
• Push notifications
• 30+ currency conversions, more than 20 languages supported

What’s next?

We’re going to continue our commitment to NANO and Natrium — Android users will be receiving the Natrium 2.0 update initially as a BETA within the next week or two.

We have a new support channel on Discord at https://support.natrium.io — feel free to stop in to report any feedback you may have.

Follow us for updates

Follow Appditto on social media to stay up to date with news and updates. Looking for a cross-platform app for your business?

Reach out at appditto.com

Twitter: @appditto

Github: @appditto

Reddit: @appditto

Natrium 2.0 — NANO Mobile Wallet now Available on the iOS App Store! was originally published in Appditto on Medium, where people are continuing the conversation by highlighting and responding to this story.